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Preface 



This book is a self-instruction course in how to design and animate screen 
images on the ATARI Computer. The book centers around what is called 
"Player-Missile Graphics (PMG)". 

The course will take you step-by-step through all of the fundamentals of 
PMG and give you "progress checks" so that you can check your understand- 
ing of the material presented. When you see a black square in the margin (like 
this ■). you will know I am about to ask you a question. Since the correct 
answer is given immediately below the question, you may wish to cover it up 
with a separate sheet of paper before you continue reading. 

You will get the most from this book if you answer each question and 
then compare your response with the one given. If your answer is incorrect, I 
suggest you reread the material preceding the question and then answer it 
again. When you're sure you understand, go on to the next section. 

Most chapters end with a sample program. I suggest you enter each 
program and save it under a unique name. Successive programs build on the 
previous ones, so when preparing a new program, first enter the one you 
typed in previously and then modify it. 

Have funl The programs all work. The one in Chapter 11 is quite involved 
and may contain some hidden bugs. I invite your help. If you find any bugs or 
come up with improvements, I would be delighted to hear from you. Write to 
me in care of Reston Publishing Company, Inc., Reston, Virginia. 
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Introducing PMG 



Surprise! Atari has a secret feature that sets it apart from most other personal 
computers. It's called Player-Missile Graphics (PMG for short). With PMG you 
can create all sorts of special graphic effects — effects that would be extremely 
difficult, if not impossible, with an Apple, IBM, or TRS-80. 



EASY IMAGE CREATION 

Once you know how, you can easily create your own "custom made" graphic 
images. Thanks to Atari's special direct memory access system (DMA), it's 
almost as easy as shading in sguares on a piece of graph paper. 



EXTRA COLORS 

You can make your "babies" any color you want. These images (or "players," 
as Atari calls them) are independent of the usual screen images. Let's say you 
are using what is called "graphics mode 5." Normally, with this mode, you are 
limited to four colors. But with PMG you can have up to nine colors, because 
each player can be a different color. 
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THREE-DIMENSIONAL EFFECTS 

PMG lets you simulate 3-D. Because players are independent of the other screen 
images, they can be set to hide behind (or go in front of) other objects. Also, it's 
really easy to change the size of a player and to make a player look like it is 
moving from a distant location into the foreground. Atari uses this technique 
effectively in STAR RAIDERS to animate the attacking spacecrafts. So can you! 



ANIMATION 

PMG greatly simplifies animation. With PMG you can move players quickly and 
smoothly with just a few commands. At the same time you can simultaneously 
create sound effects and carry out other processing. That's because PMG is 
controlled by two extra microprocessors called ANTIC and CTIA (or GTIA). 



NOT JUST FOR GAMES 

Atari first developed PMG to simplify game programming. But you can use 
PMG anywhere that animation or special screen images and colors are useful. 
For example, in an educational program you could grab the learner's attention 
with an animated arrow. The arrow could point out various parts of a diagram. 
In a music program you could use players for notes and have them dance 
across the screen along with the music. In a program that displays textual 
material, you could use players to highlight important words or sentences. 
Normally this is not so easy. Without PMG, graphic images cannot appear on 
the same line with text. 

PMG could be useful in business programs, too. For example, you could 
design an animated warning routine to catch an operator's attention when a 
crucial entry was required. It might even make the job more fun and cut down 
on data entry errors. 

LEARNING TO USE PMG 

You may be saying to yourself: "If PMG is so great, why aren't more people 
using it?" Well for one reason, it has been really hard to learn — that is, up until 
now. PMG is perhaps the most powerful, yet least understood, feature of the 
Atari computer. 

But relax. In this book we will take you step by step through everything 
you need to know to create sophisticated graphic effects far beyond the reach 
of most other micros. 
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OVERVIEW OF PMG SETUP 

Here are the major programming tasks needed to set up PMG. (Don't try to 
understand all this right now. It's just an overview. Details will come later.) 

• Design the graphic images you want to display. Then calculate the 
data needed in memory to produce these images. 

• Allocate space in memory for PMG. 

• Dimension strings that will hold player image data. 

• Set the PMG memory to zero data. 

• Read the player image into the player image strings. 

• Set the color of the players. 

• Tell Atari where the PMG memory starts. 

• Tell Atari whether you want single- or double-line resolution. 

• Turn on PMG. 

• Set the initial position coordinates for players and missiles. 

• Animate the players and missiles as desired. 

These are the basic things you'll need to get started. I'll cover them first. 
Then after you've mastered them I'll show you some advanced programming 
tricks you can amaze your friends with. "How did you do that?" they'll say. 

Now, let's get started with the first task — designing player images. 




Designing 
Player Images 



In this chapter you'll learn how to design an original graphic image that you 
can animate using Atari's special PMG features. We'll call this image a "player" 
to distinguish it from other graphic objects that may appear on the screen. 
Specifically, when you finish this chapter, you'll be able to: 

1. Lay out a player image on graph paper. 

2. Figure out the binary data required in memory to create a player. 

3. Calculate the decimal numbers needed to create a player image. 

4. Sketch out the player images that would be created by various kinds of 
data in memory. 

5. Explain what distinguishes player-missile (PM) memory from ordinary 
memory. 

Let's begin by taking a look at the way graphic images are stored in 
memory. 
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HOW IMAGES ARE STORED 

As you probably know, your Atari has several different graphics modes. In this 
discussion, I will be referring to graphics modes 3 through 8. These modes are 
for displaying pictures rather than words or letters. 

An important graphics term is pixel, short for "picture cell." (Think of 
"pic-cell.") A pixel is the smallest picture element possible. The size of a pixel 
depends on the graphics mode you are in. This next illustration shows the 
approximate size of a pixel in graphics mode 3. 




PIHEL 



If you'd like to see what a pixel actually looks like in different modes, 
trying running this program: 



(ENTER A NUMBER BETWE 
OR BM>8 THEN 10 



ULD YOU LIKE 

EN 3 AND 8) " 

20 INPUT BM: IF 6M< 

30 GRAFHICS GM 

40 COLOR 3 

50 PLOT 30, 18 

60 ? "THIS IS A PIXEL IN GRAPHICS MODE 

"5GM 
70 FOR PAUSE=1 TO 1000: NEXT PAUSE 
80 GOTO 10 



As you may know, all data in random access memory (RAM) is stored in 
consecutive memory locations called bits. (Eight consecutive bits are called a 
byte.) Each bit contains either a one or a zero. 
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A certain part of RAM is used to hold data that will be used to display 
screen images. Let's call that screen RAM. If a bit in screen RAM is set to one, 
then the corresponding screen pixel will light up. If a bit is a zero, then the pixel 
will be turned off. 

■ Suppose a byte (eight bits) contains these values: 00011000. Which of these 
diagrams correctly shows the screen image that would be displayed by 
that byte? 



A. - 



|_F ■ 



ANSWER 

A (Remember that each bit set to one causes the corresponding screen 
pixel to be illuminated.) 



ONE- AND TWO-DIMENSIONAL 
IMAGES 

Notice that image "A" above is not yet really a two-dimensional image. It has a 
horizontal dimension, but no vertical dimension. Actually, it isjust a stubby line. 
Let's make it into a two-dimensional image by turning on some pixels directly 
beneath it on lines two and three. 

LIME 2 

— LINE 3 



<- 



Now we have a two-dimensional image. It has height and width. In 
ordinary RAM it would be hard to display this image. We would have to do a 
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lot of calculating to figure out which bits in RAM to set to one. Why? Well, RAM 
is linear; it consists of a series of bytes laid end to end. It is one-dimensional. 



ONE DIMENSION 



On the other hand, screen images are two-dimensional. They have a 
horizontal and a vertical dimension. Fortunately, the Atari engineers simplified 



+ 



v 



VERTICAL 



i > 

HORIZONTAL 



all this. They arranged for the second byte in PM memory to be displayed 
directly under the image of the first byte. Similarly, the third byte is displayed 
directly under the image of the second byte, and so on. This way the data for 
an image can be stored in consecutive bytes in RAM as illustrated here: 



BYTE! BYTE2 BYTE3 



Of course, before you put any data into those consecutive bytes, you 
need to know exactly what image you want to create. So let's go over the 
procedure for designing a player image. 



DESIGNING A PLAYER IMAGE 



First, lay out a grid that is 8 columns wide with as many rows as you like up to 
128. For example, you might start with a grid that has 8 columns and 11 rows, 
like this: 
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Next, make an image by shading in selected squares on the grid. (Actu- 
ally, each square on your grid represents a pixel on the display screen.) Here's 
an example: 




In this example, how many pixels are lit up to draw the character's neck? 



ANSWER 



Just one. 
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LIGHTING UP PIXELS 

The next step is to figure out which bits in memory to set to one so the proper 
pixels are turned on. This is really quite simple. All we do is convert each row in 
our grid to a number.. 

To do that we look at each square in our grid. If the square is shaded in, 
we write down a "one." If the square is not shaded, we write down a zero. For 
example, we would convert the first row of our player like this: 



HHBI 


1 1 i i 1 : ; 




1 1 \ ! ! i 


I i | | | i I i 


' ! ! : ! ( ! 


| ■ ! i 


; i i i = 




1 1 1 i 1 ! 


i ! 



' 



o o 1 1 1 o o 



This number— 00011100— is called a binary number. Notice that it is com- 
posed of just ones and zeros. As you may know, a binary 00011100 is not at all 
the same as eleven thousand, one hundred (11,100). I'll explain this shortly if you 
don't understand binary numbers. For now, just remember that we are translat- 
ing each row of our player into a binary number. 



I did the first row; now you try the second and third. Convert them into 
binary numbers. 
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OOO III oo 






ANSWER 



00011100 (row 2) 
00001000 (row 3) 



Now would you like to do the rest? 




ooo ii i oo 

OOP II I oo 
OOOOIOOO 
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ANSWER 


a. 00011100 


g. 00011000 


b. 00011100 


h. 00101000 


c. 00001000 


i. 01001100 


d. 00011100 


j. 01000100 


e. 00111010 


k. oioooioo 


f. 01011001 





Now we have all of the binary numbers needed for our player image. But 
before we can put these values into Atari's memory, we need to convert them 
into decimal numbers. That's because BASIC was designed for inputing dec- 
imal numbers, not binary ones. 

If you already know what decimal and binary numbers are and how to 
convert from binary to decimal, you can skip ahead to "Converting the Image 
to Decimal Numbers." Otherwise, read on and I'll explain. 

Decimal numbers are the kind used by most normal people (You know 
what I mean— people who aren't assembly language programmers). The word 
part "dec" means "ten". For example, a decade is a period of ten years. The 
decimal number system contains ten different number symbols, which are: 

0, 1, 2, 3, 4, 5, 6, 7, 8, 9 

Similarly, the word part "bi" means "two." For example, bimonthly 
means "every two months." Binoculars are field glasses designed for use by 
two eyes. The binary number system uses only two kinds of number symbols: 
I's and 0's. 

Let's look at some binary numbers. To keep things simple, we'll start out 
with small binary numbers and put each number symbol in a box. 






A "1 " in this box 
represents a decimal 
"2". 



A "1 " in this box 
represents a decimal 
"1". 
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So a binary 11 represents a decimal 3 since 2 + 1=3. What, then, would this 
binary number represent? 





2 (2+0=2) 



ANSWER 



Now let's try a binary number with three number symbols. Again, we'll 
put each symbol in a box. This time, above each box, we'll show what the box 
is worth in decimal if it has a "1" in it. 



£43 £23 


£13 


1 

J. J. 


1 



/ 



A "1 " in this box 
represents 4. 



So this binary "111" represents a decimal 7 since 4 + 2+1 = 7. 

Got that? Let's see. Give me the decimal equivalent of each of these binary 
numbers: 



lie 


11 


10 
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ANSWER 



6(4+2). 3(2+1). 2 



Let's take away the boxes. What is the decimal equivalent of each of these 
binary numbers? 



a. 101 

b. 010 

c. 001 

d. Ill 



ANSWER 



a. 5 b. 2 c. 1 d. 7 



Now let's look at an eight-position binary number. We'll put the digits in 
boxes again to help you visualize the number. 

£1283 £643 £323 £163 £83 £43 £2 J £13 






This binary number is equal to 255 since: 
1 28+64+32+1 6+8+4+2+1 =255 



Now, you try one. How much is this in decimal? (Hint: compare this one 
with the previous binary number.) 

£1283 £643 £323 £163 £83 £43 £23 £13 



11111101 
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ANSWER 










253 |lt 


isji 


jst two less than the 


previous ex; 


mple. 


Notice 


we 


now have a 


"0" in 


the 


"2 box' 


instead of a 


"1." 











How about this one? 
£1283 £643 £323 £163 £83 £43 £23 £13 



00010168 




16 + 4; 



ANSWER 

20 


■ 


fry one more. 

£1283 £643 £323 £163 £83 £43 £23 £13 










1 


8 


1 


1 1 i 
i i ! 






ANSWER 

40 (32+8=40) 



CONVERTING THE IMAGE TO 
DECIMAL NUMBERS 

Now you're ready to convert your own player image to decimal numbers. 
Before you do that, however, you may wish to practice on some examples. 
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Here's the image we worked on earlier. I've done the first three rows for 
you. Try the rest if you like: 



0011 

0001 

0000 

00011100 

00111010 

01011001 

00011000 

00101 000 

01001100 

01000100 

01000100 



(4+8+16+32) 
I (16+8+4) 
00 (8) 



a 
b 
c 

d 
e 

f 

g 

h 

i 

J- 
k. 



60 
28 











ANSWER 


a. 


28 


g- 


24 




b. 


28 


h. 


40 




c. 


8 


i. 


76 




d. 


28 


J- 


68 




e. 


58 


k. 


68 




f. 


89 









If you'd like more practice in calculating decimal numbers, you may wish 
to try this next one. Otherwise, on to the next chapter. I can't wait to show you 
a new, little-known method for allocating PM memory! 



MORE PRACTICE 

■ Give the decimal numbers for creating this shape: 



■ II 


||P 

WL 

mm 


wmtm 

W&M. 


a. 

= b. 




- r) 




= f 


WW) 




= g- 


"/MM 

WM&. 




= h 
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ANSWER 


a. 


60 (32+16+8+4) 


b. 


1 24 (64 more than the previous row) 


c. 


116(124-8) 


d. 


127 (3 more than row 2) 


e. 


124 (same as row 2) 


f. 


112 (12 less than row 5) 


g- 


124 (same as row 2) 


h. 


96 (64+32) 



Congratulations. You can now design your own player image and calcu- 
late the decimal numbers needed for it. Next, you learn how to reserve memory 
for your player-missile image data. 




Dimensioning Strings 
for PMG 



In this chapter you'll learn an important secret — one not revealed in most other 
books and articles on PMG.* The secret is to use strings to store PM (Player- 
Missile) data. [If you don't know what a string is or how to dimension it, I 
suggest you see Inside ATARI BASIC by William Carris (Reston, Va.: Reston 
Publishing Company, Inc., 1982.] 

Why is this such a big deal? Because (as I mentioned earlier) Atari has the 
ability to move string data super fast. So by using strings you can achieve fast 
vertical animation without resorting to machine language! Without using 
strings, vertical movement in BASIC is slow and jerky. 



DIMENSIONING STRINGS FOR PMG 

Using this approach, you dimension a separate string at the beginning of your 
program for each of your "players." Also, you dimension one string for the 
missile area. In dimensioning these strings, there are certain rules you must 
keep in mind. 



*l'd like to thank Sheldon Leemon for his excellent article on how to use strings for fast PMG 
animation: "Take Apart: Outer Space Attack." Softside Magazine. March 1982. 
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THE BUFFER STRING 

One rule is that the beginning of PM memory is not used to display graphic 
images directly. That is, data in this beginning area are not automatically 
displayed on the screen. In this book, we will call this beginning area of PM 
memory a buffer. 

If you want, you can store player image data in the buffer and then move 
it to the display area wheneveryou want to. Here's a diagram that shows the PM 
memory area.. See if you can distinguish between the bufferand display areas. 



PLAYER 3 



PLAYER 2 



PLAYER 1 



PLAYER G 



M3 



M2 



Ml 



MO 



BUFFER 



I 



128 BYTES 



384 BYTES 



Note that this diagram shows the PM memory organization for what is 
called double-line resolution. Double-line resolution simply means that two 
lines are used to display each byte in PM memory. That is, if a bit is set to ")," 
then two pixels (one underneath the other) are lit up. We'll talk about double- 
line resolution in more detail later. Just remember that this diagram is for 
double-line resolution. Later we'll discuss single-line resolution (see Chapter?). 



Study the diagram. Then answer these questions. 

1. How big is the buffer area at the beginning of the PM memory area? 

2. In double-line resolution, how many bytes are set aside for each 
player? 
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Where does the PM display area start? 

a. 384 bytes past the beginning of the PM memory area. 

b. At the very beginning of PM memory area. 

c. Neither a nor b. 



ANSWER 



384 2. 128 3. a 



One important rule, then, is that when using double-line resolution, you 
must have a 384-byte buffer at the beginning of the PM memory area. This 
buffer area is not used to turn on screen pixels. That is, if a bit is set to "1" in this 
area, there will be no direct effect on what is displayed on the screen. That's 
why we say the actual PM display area starts 384 bytes after the beginning of 
the PM memory area. 

Another important rule is that when you are using double-line resolution, 
the PM memory area must start on what is called a "IK boundary." If you know 
what I mean by "IK boundary," you can skip to "Starting on a IK Boundary." 
Otherwise, read on and I'll explain. 



IK BOUNDARY 

A IK boundary is simply a location in memory that can be divided evenly by IK 
(1K= 1024 bytes). For example, 2048 is on a IK boundary because 1024 goes into 
2048 evenly two times. 

■ Which of these are on a IK boundary? 

a. 4096 

b. 3073 

c. 3072 









ANSWER 










a and c 


[1024 goes 


into 4096 


evenly four times 


1024 


goes 


into 3072 


evenly 


three ti 


nes). 
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STARTING ON A IK BOUNDARY 

To get your Player-Missile Base Register (PMBASE) to start on a IK boundary, 
you need to do some calculations. That's because the first string you define 
won't automatically start at any given point in memory. There are different 
ways to find a IK boundary. The method I recommend is to dimension some 
"filler strings" to take up space until the IK boundary is reached. Here is some 
code you can use to define these "filler" strings. Take a moment to look it over. 

DIM FILLER1$(1), 

FILLER2$((INT(ADR(FILLER1$)/1024)+1) 

*1024-ADR$(D$)-1) 

Note: When typing this code into your computer, you would normally 
enter it as one continuous line. I've broken it into separate lines here to make it 
easier to read. 

You don't really need to understand this filler code. All you need to know 
is that it takes up string memory until a IK boundary is reached. But, if you like, 
I'll explain; otherwise, you can skip ahead to "Setting Up PM Memory." 

UNDERSTANDING THE FILLER CODE 

Since you're so interested in the filler code, I'll rewrite it for you in a slightly 
different way so it's easier to understand: 

10 DIM FILLER1$(1) 

20 BOUNDARY = INT(ADR(FILLER1$) / 1024+1)*1024 
30 LENGTHFILLER2 = (BOUNDARY-ADR(D$)-1 
40 DIM FILLER2$(LENGTHFILLER2) 

Let's examine this code line by line, starting with line 10: 
10 DIM FILLER1$(1) 

In line 10 we define our first filler string, which we call FILLER1S. We do this so 
we have a reference point, to know where the beginning of string memory 
starts. 

20 BOUNDARY = INT(ADR(FILLER1$) / 1024 + 1)*1024 

In line 20 we calculate the address of the next IK boundary above the 
address of FILLERIS. We do this by dividing the address of FILLERIS by 1024, 
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adding 1 and throwing away the remainder. Then we multiply that answer by 
1024. (INT "throws away the remainder." ADR gives us the address of FILLER1S.) 
Let's apply this code to a simple example. Suppose the address of 
FILLER1S is 2040. We divide 2040 by 1024 and get 1.992. We add 1 to 1.992 and 
get 2.992. We throw away the remainder (.992) and get 2. Then we multiply 2 
by 1024 to get 2048, which is the IK boundary above 2024. 

30 LENGTHFILLER2 = (BOUNDARY-ADR(D$)-1) 

In line 30 we simply subtract the address of FILLERIS from the IK boun- 
dary and then subtract I from that. We subtract I because we want FILLER2S to 
fill up space right up to (but not over) the IK boundary. 

We still need to find the length of our second string, namely FILLER2S. If 
we subtract the address of FILLERIS from the next IK boundary, we would get 
8, since 2048 - 2040 = 8. But to get the proper length for FILLER2S, we need to 
subtract l from 8 (since we want to take up space just up to the IK boundary). 
Look at this diagram: 



2846 




FILLER2S 

7 BYTES 



FILLERIS 
tl BYTE) 



IK BOUNDARY 
£28483 



Suppose that the address of FILLERIS were 2030. What would the proper 
string length be for FILLER2S? 



ANSWER 



17 (2048-2030-1=17) 



This finishes our explanation of the filler code. Now let's go on to the 
next step. 
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SETTING UP PM MEMORY 

After dimensioning the filler strings, the next step is to allocate space for the PM 
memory by dimensioning additional strings. Let's look again at the way PM 
memory is organized so you can see what PM strings will be needed: 



PLAYER 3 



PLAYER 2 



PLAYER 1 



PLAYER 



M3 



M2 



Ml M8 



BUFFER 



I 



128 BYTES 






384 BYTES 



Based on this diagram, which string do you think we should define first? 

a. BUFFERS 

b. MISSILESS 

c. PLAYEROS 



BUFFERS 



ANSWER 



It's important to determine the BUFFERS string immediately after the filler 
strings. That way the buffer will start on a IK boundary. For example: 

10 DIM FILLER1$(1), 
FILLER2$((INT(ADR(A$)/1024+1 ) 
*1024-ADR(FILLER1$H) 
20 DIM BUFFER$(384) 
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Actually, line 20 isn't finished yet. Can you explain why? 



ANSWER 

It's not finished because we still need to dimension strings for the missiles 
and players. 



In doing this, we use one string for all of the missiles and a separate string 
for each of the players. 

■ With this in mind, see if you can finish line 20: 
20 DIM BUFFER$(384] 



ANSWER 

20 DIM BUFFERS(384), MISSILES$(128), PLAYERI$(128), PLAYER2S(128). 
PLAYER3$(128) 



Of course, you could use different variable names, such as MS for MIS- 
SILESS, or P0$ for PLAYER1S, and so on. Also, notice that there is only one string 
defined for all four missiles. 



PLAYER NUMBERING 

Notice that the players are numbered from zero to three. Does that seem a little 
strange to you? (It does to mel) Actually, you can name the players any way 
you want to. This kind of naming convention is often used by assembly lan- 
guage programmers. It really means that PLAYERO starts bytes from the 
beginning of the player area. Similarly, the name "PLAYER1" means that the 
player is located 1*128 or 128 bytes from the beginning of the player area. 
Similarly PLAYER2 is located 2*128 or 256 bytes from the beginning of the 
player area. 

That's guite a mouthful I know. Let's see if I got the message across: 

■ Suppose you know that the beginning of the player memory area starts on 
byte 4480. Where would PLAYER1 start? 



ANSWER 



4608 (4480+1*128=4608) 
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■ Again, assuming the player memory area starts on byte 4480, where 
would PLAYER3 start in memory? 



ANSWER 



4864 (4480+3*128=4864) 



You now know how to allocate space for the PM memory area using 
double-line resolution. Later you'll learn how to do a similar setup for single- 
line resolution. That will be easy since you've already learned the fundamental 
concepts involved. Now that we've defined our player image and allocated 
space for PM memory, let's get a player on the screen! 



" 




" I 



Getting a Player 
on the Screen 






Now that you have designed a player and have allocated space for PMG 
memory, let's see what that player looks like. 

When you finish this chapter you will be able to: 

• Write the code needed to get a player on the screen. 

• Put the player anywhere you want by specifying horizontal and vertical 
coordinates. 

• Make the player any desired color. 

• Use double-line resolution. 



To start with, let's go over the main programming tasks required to get a 
player on the screen. 



MAIM PROGRAMMING TASKS 

1. Define filler strings so that the PM strings area can start on a IK 
boundary. 

2. Allocate space for the PM memory area. 
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3. Set the PM memory area to zeros. 

4. Dimension a separate string for holding our player image data. 

5. Put our player data into that string. 

6. Specify the color of our player. 

7. Specify the location of PM memory. 

8. Specify double-line resolution. 

9. Turn on PMG. 

10. Specify the desired horizontal location of the player. 

11. Put player image into the desired vertical location. 

You have already learned to write the code for steps 1 and 2, so let's go 
on to step 3. 

Setting the PM Memory Area to Zeros 

When you run a program, the data in the string area is not automatically 
cleared out. That's why we need to explicitly set the PM memory area to zeros. 
Let's start with BUFFERS. Here's a quick way to set it to zeros: 

11020 BUFFER$=CHR$(0) 
11030 BUFFER$(384)=CHR$(0) 
11040 BUFFER$(2) = BUFFER$ 

This code may seem somewhat confusing, but rest assured — it works. 
Line ll 020 sets the first byte of BUFFERS to zero. Line 1 1 030 sets the 384th byte to 
zero. Line H040 says "start with the second byte of BUFFERS and set all the re- 
maining bytes of BUFFERS to the first byte of BUFFERS." (I know, it's a mouthful.) 

As an aside, if you wanted to set all of BUFFERS to some other value be- 
sides zeros, all you need to do is to change line 1 1 020. For example to set 
BUFFERS so that it has nothing but "X's," change line H020 to read: 

11020 BUFFER$="X" 

If you'd like to take a break from reading, you may want to enter the 
above lines and experiment with changing line 1 1 020 to see what affect it has 
on BUFFERS. If so, I suggest you start by entering these lines: 

11010 DIM BUFFER$(384) 
11020 BUFFER$="X" 
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11030 BUFFER$(384)=CHR$(0) 
11040 BUFFER$(2) = BUFFER$ 
11050 ? BUFFER$ 

Note that in line 1 1 020 we set the first byte of BUFFERS to "X." In line 1 1050 
we print BUFFERS just to see what it contains. (The question mark is short for 
"PRINT.") 

After entering the lines, type "RUN." Since all of BUFFERS has been set to 
"X,"you will see this: 



XXXXX 

xxxxx 
xxxxx 
xxxxx 
xxxxx 
xxxxx 
xxxxx 
xxxxx 
xxxxx 
xxxxx 
xxxx 



xxxxx 
xxxxx 
xxxxx 
xxxxx 
xxxxx 
xxxxx 
xxxxx 
xxxxx 
xxxxx 
xxxxx 



xxxxxxx 
xxxxxxx 
xxxxxxx 
xxxxxxx 
xxxxxxx 
xxxxxxx 
xxxxxxx 
xxxxxxx 
xxxxxxx 
xxxxxxx 



xxxxxx 
xxxxxx 
xxxxxx 
xxxxxx 
xxxxxx 
xxxxxx 
xxxxxx 
xxxxxx 
xxxxxx 
xxxxxx 



xxxxxx 
xxxxxx 
xxxxxx 
xxxxxx 
xxxxxx 
xxxxxx 
xxxxxx 
xxxxxx 
xxxxxx 
xxxxxx 



xxxxxxxxx 
xxxxxxxxx 
xxxxxxxxx 
xxxxxxxxx 
xxxxxxxxx 
xxxxxxxxx 
xxxxxxxxx 
xxxxxxxxx 
xxxxxxxxx 
xxxxxxxxx 



Now, change line 11020 so that it reads: 
11020 BUFFER$=CHR$(0) 

Run the program again. This time you will see a screen full of hearts. That's 
because the Atari code for a heart character is a zero. 



Think for a moment. Does the memory location of BUFFERS contain hearts 
or zeros? 



a. 
b. 



Hearts 
Zeros 



ANSWER 

Zeros, of course! Remember, in memory, a bit always contains either a one 
or a zero. 
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To see the zeros in BUFFERS, try running this program: 

11060 FOR 1 = 1 to 384 
11070 ? ASC(BUFFER$(I)) 

11080 NEXT I 

» 

Note: In line 1 1 070 I am using "ASC" to return the actual number stored in 
each byte of BUFFERS rather than displaying a character. 

Now that we have set BUFFERS to zeros, we can use it to set the rest of 
PM memory to zeros. For example, we can set the missile area to zeros like this: 

MISSILES$=BUFFER$ 

■ You try it. Assume that BUFFERS has already been set to zeros. Then, write 
the statements needed to set the entire PM memory area to zeros. (Re- 
member, besides BUFFERS, our PM memory area contains these strings: 
MISSILESS, PLAYER0S, PLAYERIS, PLAYER2S, PLAYER3S.) 



ANSWER 

MISSILESS=BUFFER$:PLAYERO$=BUFFER$: 
PLAYER1$=BUFFER$:PLAYER2$=BUFFER$: 
PLAYER3S=BUFFER$ 



Player Image String 

Besides dimensioning the PM memory area and setting it to zeros, we need to 
dimension a string to hold our player image data. We'll call it "IMAGE1S," 
meaning "image one for player one." As you will see later, we will want to 
have more than one image for each of our players so that we can do things like 
make their legs move. 

Dimensioning the string is easy: 

DIM IMAGE1$ 

Putting the proper data into a string is a bit harder. First, you need to 
know how to refer to specific bytes of a string. If you alredy know how to do 
that, you may wish to skip ahead to "Putting Data into IMAGEIS." 

Referencing Specific Bytes 

In Atari BASIC, you can refer to specific sections of a string variable by numbers 
in parentheses after the name of the string. The first number gives the starting 
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byte of the section of the string you want to refer to. The second number gives 
the ending byte. For example, to refer to the first three bytes of a string called 
STORAGES, we would write: 



STORAGES CI, 35 



FIRST 
BYTE 



LAST 
BYTE 



How would you refer to bytes 5 through 9 of STORAGES? 



ANSWER 



STORAGES(5.9) 



If you want to refer to a single byte, just list the number of that byte twice. 
For example, to refer to byte 5 of STORAGES, you would write: 

STORAGE$(5,5) 

■ How would you refer to byte 1 5 of STORAGES? 



ANSWER 



STORAGES(15,15) 



Putting Data into IMAGE1S 

To get out player image data into the string we use a "FOR-NEXT" loop. Our 
first statement in this loop is: 

FOR 1 = 1 to 15 

This sets up the loop so that I is set to I the first time through the loop. The next 
time through the loop, I will be set to 2 and so on until I is 15. 



Can you guess why we need to make 15 passes through the loop? 
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ANSWER 

When we created our player, we had 15 rows in our matrix. We had a 
number for each row. These numbers will first be stored in data state- 
ments. Each time through the loop we will read a number and then put it 
into IMAGE1S. Since we will be adding two rows of zeros at the top of the 
matrix and two rows at the bottom, we have 15 numbers altogether. 



Here is the complete loop for putting all 15 numbers into IMAGEIS: 
FOR 1 = 15:READ A : IMAGE1$(I,I) = CHR$(A):NEXT I 

Let's look at each statement separately. We've already discussed "FOR I=l5." 
The next statement is "READ A." 

READ A This simply gets a number contained in a data statement and puts it 
in variable A. 

IMAGE1S(I,I)=CHRS(A) This statement puts the number into successive bytes 
of IMAGEIS. Note the (1,1). The first time through the loop the variable I will be 
set to 1. So the statement will be equivalent to: 

IMAGE1$(1,1)=CHR$(A) 

This means set the first byte of IMAGEIS to the contents of variable A. The 
second time through the loop, I will be set to 2. So the statement will be 
equivalent to: 

IMAGE1$(2,2)=CHR$(A) 

■ What does this mean? 



ANSWER 
Set the second byte of IMAGEIS to the contents of A. 



Now let's talk about CHR$(A). We need this because the variable A is 
numeric. You can't put numeric data into a string directly. It has to be converted 
to string data (also referred to as character data). That's what CHRS does. It 
takes whatever number is in parentheses and gets the corresponding character, 
which can then be stored in the string. 

I What do you think would happen if we simply wrote: 
IMAGE1$=A 
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ANSWER 








Actually Atari's syntax checking feature won't even let us enter a statement 
like this. If we try to, the word "ERROR" appears, and the "A" will be 
displayed in inverse video showing that something else probably needs to 
come after the equal sign. 



Now that we have set the PM memory area to zeros, our next step is to 
specify what color we would like our player to be. 

Specifying Player Color 

You can easily control the color of a player by putting a number into a memory 
location. Here are the locations for each of the players: 

Player Location 

704 

1 705 

2 706 

3 707 



(For your convenience these locations are also summarized in Appendix A.) 

If you use graphics modes 3, 5, or 7, then you can use the following 
numbers as a guide for designating your player's color: 

Color Number 

Gray 

Gold 16 

Orange 32 

Red " 48 

Pink 64 

Violet 80 

Purple 96 

Blue 112 

Blue 128 

Light Blue 144 

Turquoise 160 

Blue-Green 176 

Green 192 

Yellow-Green 208 

Orange-Green 224 

Light Orange 240 
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These are starting numbers. To any given number you can add an even 
number from to 14 to change the lightness of the color. For example, for a 
light green color you might add 14 to 192 and use 206 as the color number. For 
a darker green you might add, say, 4 to 192 and use 196. 

■ Would 48 give you a bright red or dark red color? 



ANSWER 



Dark 



What number would you use for a light red? 



ANSWER 



62 (48+l4| 



You might also use 56, 58, or 60 for a light red, depending on how light a 
shade you want. Notice that when you go beyond 62, you start moving into 
pink. 

Poking the Color Number 

You can use the Poke command to specify the player's color. To specify a dark 
gold color for player 0, you might write: 

POKE 704,16 

■ Write a command to set player 2's color to dark violet. 



ANSWER 

POKE 706,80 (You might also use 82, 84, or 86 for dark violet. The lower the 
number, the darker the color.) 



Specifying Start of PM Memory 

The Atari microprocessor called ANTIC automatically takes care of displaying 
PM images on the screen. But before ANTIC can do that we have to tell it 
where PM memory starts. To do that we simply POKE the proper address into 
location 54279. Since our PM memory area is string memory, we can use the 
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ADR function. The ADR function gives the address of the string that follows it in 
parentheses. For example: 

ADDRESS=ADR(STORAGE$) 

After this statement is executed, the variable ADDRESS will contain the starting 
address of the string area called STORAGES. 

■ Recall the structure of the PM memory area. What is the first string in the 
PM memory area? 



ANSWER 

BUFFERS (Remember this area? It's sort of a multipurpose PMG storage 
area. Data stored here does not display on the screen). 



How would you refer to the address in memory where BUFFERS starts? 



ANSWER 



ADR|BUFFERS) 



From what you've learned, see if you can write a statement to inform 
ANTIC of the location of the PM memory area. 






ANSWER 

POKE 54279,ADR|BUFFERS) (We poke the address of BUFFERS into 54279 
because the address of BUFFERS is the same as the address of the start of 
the PM memory area.) 



PMBASE 



Location 54279 is known as the Player-Missile Base Register (PMBASE). If you 
initialize a variable called PMBASE to 54279 at the beginning of the program 
like this 

PMBASE=54279 

then we can tell ANTIC where PM memory starts by writing a statement like 
this: 
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POKE PMBASE,ADR(BUFFER$) 

Did you notice how I use the word "register" above to refer to a memory lo- 
cation? (Player-Missile Base Register=location 54279.) Remember, in data pro- 
cessing, a register is nothing more than a memory location dedicated to a 
specific purpose. Usually we put data into a register to control the computer's 
operation. 

Specifying Resolution 

Another important register is the one used to specify resolution. We touched on 
resolution earlier, but now let's consider it in more detail. With PMG you have 
your choice of either double- or single-line resolution. Single-line resolution 
means that when ANTIC sees a "I " in PM memory it will light up a single pixel. 
In double-line resolution, when ANTIC sees a "1" in PM memory it lights 
up two pixels. Both pixels will be right underneath each other on two separate 
lines (hence the name double-line resolution). Perhaps an illustration will help 
clarify this. Suppose you have this binary data in PM memory: 

00011100 

00011100 

00001000 

00011100 

00111010 

01011001 - 

00011000 

00111100 

00100100 

00100100 

01100110 

With single-line resolution, your player will look like this: 
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With double-line resolution, you will get a player that looks like this: 




Which kind of resolution gives you a more "blocky" looking character? 
Which one looks more "detailed"? 



ANSWER 

Double-line resolution results in a more "blocky" looking player. You get a 
more detailed looking figure with single-line resolution. 



So far we have been using double-line resolution. How many bytes per 
player does double-line resolution require? (Hint: look back at how we 
dimensioned each player.) 



ANSWER 



128 



If we were to use single-line resolution we would need twice as many 
bytes for each player because each bit in memory only lights up one pixel. 

■ How many bytes would each player need in single resolution? 



ANSWER 



256 
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Keep in mind that if we dimension our players for 128 bytes, then we 
must use double-line resolution. We can't change to single-line resolution, 
unless we change the way we dimension PM memory. Also, the filler strings 
(remember them?) must be dimensioned differently because single-line resolu- 
tion must start on a 2K boundary. (More on single-line resolution later.) 

■ We can ask for double-line resolution by poking location 559 with 46. 
How would you code that? 



ANSWER 

POKE 559,46 



Location 559 is called the direct memory access control register (DMACTL). 
It is used for more than just specifying the type of resolution. We'll talk more 
about DMACTL later. For now just note that you need to poke it with 46 to ask 
for double-line resolution. As we did before, you could use DMACTL as a 
variable in place of "559." At the beginning of the program you could write: 

DMACTL = 559 
■ What is the other statement needed to ask for double-line resolution? 



ANSWER 

POKE DMACTL.46 



Turning on PMG 

Another important register is memory location 53277, called the graphics con- 
trol register (GRACTL). You use GRACTL to "turn on" the PMG system. You 
have different options here. You can turn on just players, just missiles, or players 
and missiles. Here's how you do it: 

If you want: Then: 

Missiles only POKE 53277,1 

Players only POKE 53277.2 

Players and missiles POKE 53277,3 

■ Suppose you want to use players and missiles. How do you specify this 
with the GRACTL register? 
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ANSWER 



POKE 53277,3 






Using Register Abbreviations 

If you want, you can also initialize the variable GRACTL to 53277 at the begin- 
ning of your program like this: 

GRACTL=53277 

Then, to turn on PMG with both players and missiles, you could write: 

POKE GRACTL.3 
■ Can you think of a disadvantage in doing it this way? An advantage? 



ANSWER 

It takes a little more memory to initialize GRACTL to 53277. Also, it uses up 
a variable. In Atari BASIC you are limited to 128 variables. The advantage is 
that your code is somewhat easier to read. 



Well, we're almost there. Once you have taken care of these steps you 
have completed the task of setting up PMG. Often you will need to carry out 
these steps only once, so it's a good idea to put the code needed to do this into 
a subroutine. 

Assigning Line Numbers As a rule of thumb, I suggest you assign high 
numbers to subroutines that will be performed just once or when speed is not 
critical. That's because when Atari BASIC executes a subroutine, it has to search 
for it sequentially, starting with the lower line numbers. 

■ Because the PMG setup routine will usually be done just once at the 
beginning of the program, which of these line numbers do you think 
would be most appropriate for it? 

a. 100 

b. 500 

c. 11000 









ANSWER 








C. 11000 


(That 


way you will 


save the lower 


line 


numbers 


for routines 


where s 


oeed is 


important). 
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Once the setup routine is complete, all you need to do is say where you 
want the player to appear on the screen horizontally and vertically. Let's take 
the horizontal specification first, since it's the easiest. We use a set of registers 
for that— the horizontal position registers for players (HPOSPO to HPOSP3). 



" 



HPOSPO 

HPOSPO is the horizontal position register for player 0. It is memory location 
53248. 

Here are the values you poke for various horizontal screen locations: 



■ ■ ■ ■ ■ 

t t 1 t t 



50 80 120 160 200 



HORIZONTAL 
COORDINATES 



Check your understanding: 



Write a statement to put player at the: 

1 . Left edge of the screen. 

2. Right edge of the screen. 

3. Center of the screen. 



" 
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ANSWER 


1. 


POKE 53248.50 


or 


POKE HPOS0.50 


2. 


POKE 53248.200 


or 


POKE HPOS0.200 


3. 


POKE 53248,120 


or 


POKE HPOS0.120 



Where do you think the horizontal position register is for: 

1. player 1 

2. player 2 

3. player 3 





ANSWER 


1. 

2. 
3. 


HPOSP1 =53249 (one more than 53248) 

HPOSP2=53250 

HPOSP3=53251 



Often it's handy to use a variable to specify the value to be poked into the 
horizontal position register. For example, you might use HI to designate the 
horizontal coordinate for player I. Then you would write: 

POKE 53248, H1 or POKE HPOS0,H1 

More on why this is useful later. Let's now look at how you set the 
vertical position of a player. 



Vertical Position 

Atari BASIC doesn't have a vertical position register. So specifying vertical posi- 
tion can be a problem. But because we use string memory for PMG, it's easy to 
specify vertical position. First, set a variable like, say, "vert" to the desired value: 

VERT=30 

Then use a string command to set the player string to the data contained in the 
player image string, like so: 

PLAYER0$(VERT) = IMAGE1$ 

Remember our discussion of how string commands work? The value in 
parentheses after the string specifies the starting byte. If VERT equals, say, 30, 
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then the data in IMAGE1S will be placed in PLAYEROS starting with the 30th 
byte. This has the effect of displaying our player at vertical position 30. 

■ If we wanted to position our player at vertical position 80, we would poke 
the image data into the 80th byte of the player string. Altogether our player 
string has 128 bytes, so how many vertical positions do we have available? 



ANSWER 

128 (since each player string has 128 bytes). 



Write the two statements needed to put player 1 at vertical position 80. Use 
the data contained in IMAGE1S. Use the variable VERT to specify the 80th 
byteofPLAYERlS. 



ANSWER 



VERT=80 
PLAYER1$(VERT)=IMAGE1$ 



TRYING IT OUT 

Well that's itl Now let's put this all together and get that player on the screen. A 
complete program appears on the next page. Look it over briefly. Then read the 
comments that follow it. For your convenience, I have listed the program so 
that each line has no more than 38 characters. This way the printed listing will 
match up with your screen listing. 

Caution: Be careful in typing X0 and Y0 at lines 13000 and 13010 (and 
elsewhere in the program). "X0" is "X zero," not "XO." Notice the difference? 
The zero is more oval shaped than the letter "O." 

The zero represents player number 0. "X0" contains the horizontal posi- 
tion for player 0. "Y0" contains the vertical position for player 0. Of course, you 
can adopt any variable naming scheme that you want. Just be consistent. 
Don't type "Y0" one time and "YO" the next. 



Comments on Program 

This program will let you look at all the different colors that a player can be. We 
have already gone over the code in detail so I will just comment briefly on a 
few points of interest. 
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1 GOSUB 2000: REM SETUP ROUTINES 

2 GOTO 200: REM JUMP TO MAIN ROUTINE 

3 SAVE "D: ONSCREEN. SAV": STOP : REM BISK 
30 

199 REM MAIN ROUTINE 

200 FOR KOLORO=0 TO 254 STEP 2 
210 POKE 704,K0L0R0 

220 ? "PLAYER COLOR NUMBER-" 5 KOLORO 

230 GOSUB DELAY 

240 NEXT KOLORO 

250 END 

260 REM 

270 REM 

280 REM 

290 REM 

1999 REM SETUP ROUTINES FOLLOW. 

2000 GOSUB 10000:REM MISC. INITIAL- 
IZATION 

2005 GRAPHICS 5: REM SET BR. MODE 

BEFORE PMG SETUP/ 

2010 GOSUB 11 000: REM PMG SETUP 

2015 GOSUB 12000: REM DRAH PL AY FIELD 

2020 GOSUB 13000: REM PLAYER COLOR AND 

SCREEN POSITION 

2130 RETURN 

5000 FOR PAUSE=1 TO 500: NEXT PAUSE: RET 

URN 

10000 REM MISC. INITIALIZATION 

10050 DELAY=5000: RETURN 

10999 REM PM6 SETUP ROUTINE 

11000 DIM FILLER1*(1) ,FILLER2*( (INT (AD 
R(FILLER1*)/1024)+1)#1024-ADR(FILLER1* 
)-l> 

11010 DIM BUFFER* (384) , MISSILES* (128) , 

PLA YERO* ( 1 28 ) , PLAYER 1 * ( 1 28 ) , PL A YER2* ( 1 

28) ,PLAYER3*(128) 

11020 BUFFER*=CHR*(0) 

1 1 030 BUFFER* ( 384 ) =CHR* ( O ) 

11040 BUFFER* (2) =BUFFER* 

1 1 045 M I SS I LES*=BUFFER* : PLAYERO*=BUFFE 

R*: PLAYER1*=BUFFER*: PLAYER2*=BUFFER*: P 

LAYER3*=BUFFER* 

11050 DIM IMAGE1*(15) 
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11060 FOR 1=1 TO 15: READ A: IMAQE1* < I , I 

)=CHR*(A) :NEXT I 

11080 POKE 54279, ADR (BUFFER*) /256: REM 

DTELL ANTIC WHERE START OF PM MEMORY I 

S 

11085 POKE 559, 46: REM DOUBLE LINE RES. 



11090 POKE 53277, 3: REM TURN ON PMG 
11095 RETURN 

11300 DATA 0,0,28,28,8,28,58,89,24,40, 
76,68,68, 0, 0, 

11999 REM BRAN PLAYFIELB 

12000 SETCOLOR 4,16,2:C0L0R 1 
1 20 1 PLOT , 20 : DRAWTO 40 , 20 

12020 COLOR 3: DRAWTO 60, 35: COLOR 2:DRA 
WTO 79,35 
12030 RETURN 

12999 REM SET PLftVER COLOR AND 
POSITION 

13000 X0=175:REM HORIZONTAL PLAYER 
POSITION. 

13010 Y0=73:REM VERTICAL PLAYER 

POSITION 

13020 POKE 704,0: REM INITIALIZE PLAYER 

COLOR TO ZERO 
13030 POKE 53248, XO: REM POME HORI- 
ZONTAL VALUE INTO HORIZONTONAL 
POSITION REGISTER. 

13040 PLAYER0*(Y0)=IMA6E1*".REM PUT 
IMAGE INTO PROPER BYTE OF PLAYERO. YO 
DETERMINES VERTICAL POSITION 
13050 RETURN 



Line 1: GOSUB 2000 As you can see I start the program by "calling" a 
subroutine at line 2000. The purpose of this subroutine is to take care of what 
are sometimes called "housekeeping routines." These are routines that you 
usually only need to do once at the beginning of the program. By using high 
line numbers for these setup routines, I leave space at the beginning of the 
program for the main routine. This is preferable because routines requiring 
transfer of control (GOTOs or GOSUBs) execute faster if they are placed at the 
beginning. This will become more important later when our main routine 
becomes more complex. 
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Notice that the subroutine at line 2000 calls these additional setup 
routines: 

10000 Miscellaneous Initialization 

11000 PMG Setup 

12000 Drawing of Playfield 

13000 Beginning Player Color and Screen Position 

The "playfield" referred to here is simply the screen image that the player 
moves around on. In this case, I have used a few PLOT and DRAWTO state- 
ments to create a simple playfield. Notice that I set the graphics mode before 
doing the PMG setup. This is important because once the PMG setup is done, 
the graphics mode should not be changed. (Actually, you could change the 
graphics mode after setting up PMG, but then you need to call the PMG setup 
routine all over again.) 

I won't go into the details of how to create playfields. For details on 
playfield creation, you may wish to refer to Designs from Your Mind with Atari 
by Tom Rowle (Reston, 1983). 

Line 2: GOTO 200 Obviously this line transfers control to line 200. But why? 
Simply because we want to jump over line 3, which is really not part of the 
program. 

Line 3: SAVE 'D.ONSCREEN.SAV'.STOP I use this line to save the pro- 
gram to disk after I've made changes to it. It's really quite handy. After I've 
finished editing the program, I just type G.3 and the program starts saving itself! 
(Atari understands that "G." is an abbreviation for "GOTO.") Notice the com- 
mand "STOP" at the end of line 3. This keeps the program from continuing to 
execute after it saves itself. 

Line 200 to 240 Here is where the main "activity" in the program occurs. 
Notice that I have created a loop in which successive even numbers are poked 
into location 704, which is the color control register for player 0. 



AW ASSIGNMENT 

I suggest you type the program into memory. Then save it by typing G.3. Next, 
try running it. If it doesn't work, proofread your work carefully. Watch out for 
typos! They are especially destructive when you are working with PMG. That's 
why it's important to save the program before running it. 
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Once the program is working, you may wish to try modifying it slightly. 
That's the best way to learn. For example, you might try changing the values 
following the SETCOLOR command at line 13000. If you do, notice how this 
affects the color of the playfield and the player. Or, try changing the horizontal 
and vertical position of the player. You can do that by changing the values 
assigned to X0 and Y0 in the subroutine starting at line 13000. Happy hacking! 




w 



Animating Your Player 



So far you have learned to design a player image and carry out the necessary 
PMG setup routines needed to display it on the screen in any desired color. 
After finishing this chapter you will be able to move your player around on the 
screen with or without joystick control. 

Animation of a player without joystick control is much easier to program, 
so let's start with that first. 



ANIMATION WITHOUT A JOYSTICK 

Once you have a PMG setup routine working, it's quite easy to produce 
different results with minor program changes. In the program in the previous 
chapter we established the position of our player with the statements "X0=175" 
and "Y0=75." We used XO to specify the horizontal position and YO to specify 
the vertical. In our new animation program, we will still use these statements to 
tell where we want the player first positioned. But after that we will set up a 
loop in which we will either increase or decrease the values in XO and YO. (We 
will use XO for the horizontal position of player since "X" in mathematics 
traditionally refers to the horizontal plane. Similarly, "Y" usually refers to the 
vertical plane. So I use YO to control the vertical position of the player.) 



47 
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Main Program Loop 

Here is the start of the main loop of our new program. 

■ As you examine this code, see if you can tell which statement puts the 
program into a never-ending loop. 

1 GOSUB 200:GOTO 190 

2 SAVE"D:MOVE.SAV":STOP 
190 SP=1 

200 POKE 53248, X0 

220 PLAYER0$(Y0) = IMAGE1$ 

230 GOTO 230 



ANSWER 



The "GOTO" statement on line 230 puts the program into a never-ending 
loop. 



Note that because the program is looping, the horizontal and vertical 
positions of the player are constantly being set. With every pass through the 
loop we have the opportunity to change the player's position. For example, to 
move the player up the screen, all we need do is decrease the value in Y0. We 
can do this with the statement Y0=Y0-l. A better way, though, is to use the 
statement YOYO-SP, where SP is a variable set to "I." This way you have more 
flexibility. You can easily set SP to a different value and the player will move 
more or less rapidly. 

■ Now, take a look at the code above for a moment and decide where we 
need to put YOY0-SP to make the player move up the screen. 



ANSWER 

To make the player move up the screen, we need to insert the statement 
somewhere between lines 200 and 230. Notice that the statement must be 
within the loop so that the value in Y0 decreases with each pass through 
the loop. 

Try it. Load the program you typed in from the previous chapter. (You did 
type it in didn't you?) Then make these changes: 
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1. Delete lines 2,3,200,210,220,230,240, and 250 

2. Change lines 1 and 13020 to read as follows: 

1 GOSUB 2000:GOTO 190 
13020 POKE 704,88 

3. Add these lines: 

2 SAVE"D:MOVE1.SAV":STOP 
190SP=1 

200 POKE 53248.X0 

220 PLAYER0$(Y0)=IMAGE1$ 

225 Y0=Y0-SP 

230 GOTO 200 



Important: again, watch out that you don't confuse X0 with XO. "X0" is "X 
zero." Similarly, "Y0" is "Y zero" not YO. Remember that a zero has a different 
shape than the letter "O." 

Run the program. When you've got the player moving up and off the 
screen, continue reading below. 

Error 5 What happened when the player disappeared off the screen? You 
should have gotten Error 5: "String Length Exceeded." I'll show you how to 
handle this problem later. For now, just know that this error is to be expected 
wheneveryour player moves too far up or down. It happens whenever Y0 is set 
to a number less than I or greater than 1 28. That's because PLAYER0S is dimen- 
sioned to 128 bytes. On line 220 we are moving data into PLAYER0S at the byte 
specified by Y0. Because there is no such thing as byte for a string, a value of 
in Y0 results in an error. 

As soon as you get Error 5, try this: Print the value in Y0. (Type ? Y0 and 
press RETURN.) You will notice that Y0 contains "0," an illegal value! 



Horizontal Movement 



By now you may already know how to move the player horizontally. 
Assuming that you take out line 225, what statement would you need to 
put into the loop to make the player move horizontally across the screen 
from right to left.? 
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ANSWER 



XO=X0-SP 



Try it. First insert "REM" at the beginning of line 225 so that line 225 will 
not be executed. Then insert X0=X0-SP, as line 227. When you run the program, 
the player should move from right to left across the screen. Again, don't worry 
about the error message that occurs when the player runs off the screen. This 
time you will get Error 3: "Bad Value." The bad value this time will be a -1 in XO. 
We'll handle this problem later. 

Diagonal Movement 

Now let's try diagonal movement. First, let's position the player at the top left 
corner of the screen. We do this by changing lines 13000 and 13010 so that they 
read: 

13000X0=52 
13010 Y0=1 2 

For the moment also change line 230 to "GOTO 230." When you run the 
program, the player will appear at the top left corner of the screen and just stay 
there. 

■ Now let's make him run diagonally. See if you can come up with the 
statements required to make that happen. The compare your code with 
mine. 



ANSWER 



To make the player move diagonally, change lines 225, 227, and 230 as 
follows: 

225 Y0=Y0+SP 
227 X0=X0+SP 
230 GOTO 200 



Try it! 



Now here's another one. Write the statements needed to move the player 
diagonally (as before). But when she reaches vertical position 45, move her 
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horizontally from left to right until she reaches horizontal position 125, at 
which point just have her stop. Write the necessary code in the space 
provided. Then try it out and debug it as necessary. It may take a bit of 
experimenting to get it to work. Finally, compare your code with mine. 



ANSWER 



Here's one way of doing it: 

200 POKE 53248.X0 

220 PLy\YER0S(Y0)=IMAGElS 

225 Y0=Y0+SP 

227 X0=X0+SP 

230 IF Y0>45 THEN Y0-45 

235IFX0>125THENX0=125 

240 GOTO 200 



Note: Lines 200-227 could be combined into a single line. This would 
make the player move slightly faster. But to make these programs easier to read, 
I'm putting each statement on a separate line. 

Well, moving a player without a joystick was fairly simple. Moving her 
with ajoystick is not quite so easy. 



JOYSTICK CONTROL 

To control the movement of a player with ajoystick, you need to: 

• Read the joystick. 

• Figure out the position that the stick has been moved to. 

• Change the value of X0 or Y0 accordingly. 

Reading the stick is easy. For example, this statement will read joystick 
(the one on the far left) and put a numerical value in "S:" 

S=STICK(0) 

Note: The place where you plug in joystick is labeled "Controller Jack 
1." Similarly, "Controller Jack 2" is the label for the port forjoystick 1, and so on. 

This diagram shows the various numbers that will be read into "S" when 
the joystick is moved to each position. 
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" 



Suppose you move the joystick to the right. What will be the value of "S" 
after the statement S=STICK(0) is executed? 



7 


ANSWER 


■ What is the value of "S' 
normal resting position? 


when the joystick is not moved, but left in its 


15 


ANSWER 



You can handle the values put into "S" in different ways. Here's one 
simple way: 

S=STICK(0) 

IFS=7 THENX0=X0+SP 

IF S=11 THENX0=X0-SP 

IFS=14THEN Y0=Y0-SP 

IFS=13THEN Y0=Y0+SP 

IF S=6 THEN Y0=Y0-SP:X0=X0+SP 

IF S=10 THEN Y0=Y0-SP:X0=X0-SP 

IF S=9 THEN Y0=Y0+SP:X0=X0-SP 

IFS=5 THEN Y0=Y0+SP:X0=X0+SP 
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This works. But look at all those IF-statements! They slow down program 
execution and make it difficult to get smooth and lively animation. Actually, 
you don't need to use any IF-statements at all. You don't even need the STICK 
statement.* 

For maximum speed, it's better to peek into memory location 632 to read 
joystick 0, like this: 

PEEK(632) 

Forjoystick 1 we would use "PEEK(633)," forjoystick 2, "PEEK(634|" and so on. 

Now, to handle the joystick value without "IF-statements," we will 
simply use a GOSUB command. A powerful feature of Atari BASIC is that you 
can use a PEEK command in combination with a GOSUB statement. 

■ Suppose you pull straight back on joystick 0. What value will be in memory 
location 632? (Look at the joystick drawing if you need to.) 



ANSWER 



13 



Now suppose we write this statement: 
GOSUB PEEK (632) 

To which subroutine will the program go ifyou pull back on the joystick? 



ANSWER 






It will go to the subroutine starting at line 13 (since 


location 632 will 


contain 


a 13 when the joystick is pulled backward). 







MODIFYING THE PROGRAM 

Now let's modify our program again. At line 10050 let's initialize a variable 
called "JOYSTICK" to 632. And while we're at it, let's initialize HPOS0 to 53248, 



* Thanks go to that wild and wacky game programmer, Robert Sombrio, for showing me the fast 
joystick reading routine presented in this chapter. I tested it against a machine language subroutine 
published in a major magazine. Robert's routine won hands downl 
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and SP to 1 also at line 10050. Then we can peek into "JOYSTICK" to determine 
which subroutine to execute. Line 10050 will then read: 

10050 JOYSTICK=633: 
HPOSP0=53248: 
SP=1: 
RETURN 

Our main loop will then look like this: 

200 GOSUB PEEK(JOYSTICK): 
POKEHPOSP0.X0: 
PLAYER0$(Y0)=IMAGE1$: 
GOTO 200 

Now we also need something at lines 5, 6, 7, 9, 10, ll, 13, 14, and 15. Here 
are lines 5, 6, 7, 9, and 10: 

5 X0=X0+SP:Y0=Y0+SP:RETURN 

6 Y0=Y0-SP:X0=X0+SP:RETURN "■ 

7 X0=X0+SP:RETURN 

9 X0=X0-SP:Y0=Y0+SP:RETURN 

10 X0=X0-SP:Y0=Y0-SP:RETURN 

■ To complete the routine, we need to add lines II, 13, and 14. See if you can 
write line 11: 



ANSWER 

11 X0=X0-SP (If the joystick is moved left, location 632 will contain II. To 
move our player to the left, we decrease X0 by one with "X0=X0-l"). 



Now write the code for lines 13 and 14. (If location 632 contains 13, the 
joystick was moved down; if location 632 contains 14, the joystick was 
moved up.) 



ANSWER 



13 Y0=Y0+SP.RETURN 
I4Y0=Y0-SP.RETURN 
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How about line 15? If the joystick is not moved at all, location 632 will 
contain 1 5. In this case we don't want to change the XO or YO values at all 
but simply return from our subroutine. Given that information see if you 
can write line 15. 



ANSWER 

15 RETURN 



To clean up the program, be sure to delete lines, 2, 190, 220, 225, 227, 230, 235, 
and 240 since they are not needed for joystick control. 

Also, after deleting line 190, be sure to change line 1 to: 

1 GOSUB 2000:GOTO 200 

On the next page you will find a complete listing of the program for moving a 
player underjoystick control. Try it out. When you've got it running, continue 
reading and we'll make a few more changes. 

SETTING DISPLAY PRIORITIES 

Another nice feature of PMG is that you can make players hide behind certain 
playfield objects, yet come out in front of others. This is called setting display 
priorities (or often simply "picking a priority option"). When you are program- 
ming in BASIC, you'll use memory location 623 as the priority register.* (This 
register is also used for other purposes, but one thing at a time!) 

You can set various display priorities by poking either l, 2, 4, or 8 into 
location 623. If you poke 1 into location 623, players will show up in front of all 
playfields. Furthermore, player will appear in front of player 1, player 1 will 
appear in front of player 2, and so on. 

If you poke 2 into location 623, then players 2 and 3 will appear behind 
all playfield objects. Players and 1 will still appear in front of all playfield 
objects. 

If you poke 4 into location 623, then all playfields will appear in front of 
all players. 

If you poke 8 into location 623, then players will go behind some 
playfields and in front of others. In our sample program players will go behind 



'Location 623, technically, is the shadow of hardware register 53275. A shadow is a RAM register 
as opposed to a ROM hardware register in an Atari chip like GTIA. Thirty times a second the 
operating system takes whatever value is in the shadow register and sticks it into the corresponding 
hardware register. 
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1 GOSUB 2000: GOTO 200 

2 SAVE "D ; MOVE l.SAV": STOP : REM BISK 30 

4 REM ADJUST HORIZONTAL & VERTICAL 
COORDINATES 

5 xo=xo+sp:yo=yo+sp: RETURN — 

6 yo=yo-sp: xo=xo+sp: return 

7 xo=xo+sp: return 

9 xo=xo-sp: yo«yo+sp: return 

10 xo=xo-sp: yo=yo-sp: return 

11 xo=xo-sp: return 

13 yo=yo+sp: return 

14 yo=yo-sp: return 

15 RETURN 

199 REM MAIN LOOP 

200 GOSUB PEEK (JOYSTICK) : POKE HPOSPO, X 
: PL A YERO* ( YO ) - 1 MAGE 1 * : GOTO 200 

260 REM 
270 REM 
280 REM 
290 REM 

1999 REM SETUP ROUTINES FOLLONi 

2000 GOSUB 1 0000: REM MISC. INITIALI- 
ZATION 

2005 GRAPHICS 5: REM SET GR. MODE 

BEFORE PMG SETUP/ 

2010 GOSUB 11000:REM PM6 SETUP 

2015 GOSUB 12000: REM DRAM PL AVE I ELD 

2020 GOSUB 13000: REM PLAYER COLOR AND 

SCREEN POSITION 

2130 RETURN 

10000 REM MISC. INITIALIZATION 

1 0050 J OYST I CK=632 : HP0SP0=5324B : SP= 1 : R 

ETURN 

10999 REM PMG SETUP ROUTINE 

11000 DIM FILLER1*(1> ,FILLER2*( (INT (AD 
R(FILLER1*) /1024>+1)*1024-ADR(FILLER1* 
)-l> 

11010 DIM BUFFER* (3B4) , MISSILES* (128) , 
PLAYER0*(128) , PLAYER 1$ ( 128) , PLAYER2* ( 1 
28) , PLAYER3*(128) 
11020 BUFFER*=CHR*(0) 
11030 BUFFER* (384) =CHR*(0) 
11040 BUFFER* (2) =BUFFER* 
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11045 missiles*=buffer*:playero*=buffe 

r*: player1*=buffer*: player2*=buffer*: p 

layer3$=buffer* 

11050 dim image1*<15> 

11060 for 1=1 to 15: read a: image1* ( i , i 

)=chr* (a) :next i 

11080 poke 54279, adr (buffer*) /256: rem 

dtell antic where start of pm memory i 

S 

11085 POKE 559, 46: REM DOUBLE LINE RES. 

11090 POKE 53277, 3: REM TURN ON PMB 
11095 RETURN 

11300 DATA 0,0,28,28,8,28,58,89,24,40, 
76, 68, 68, 0, 

11999 REM BRAN PLAYFIELD 

12000 SETCOLDR 4, 16, 2: COLOR 1 
1 20 1 PLOT , 20 : DRAWTO 40 , 20 

12020 COLOR 3: DRAWTO 60, 35: COLOR 2:DRA 
WTO 79,35 
12030 RETURN 

12999 REM SET PLOVER COLOR AND 
POSITION 

13000 X0=52 
13010 Y0=12 
13020 POKE 704,88 

13030 POKE 53248, XO: REM POKE HORI- 
ZONTAL VALUE INTO HORIZONTONAL 
POSITION REGISTER. 

13040 PLAYER0*(Y0)=IMAGE1*:REM PUT 
IMAGE INTO PROPER BYTE OF PLAYERO. YO 
DETERMINES VERTICAL POSITION 
13050 RETURN 



playfield objects drawn with color 1 or 2, but in front of objects drawn with 
color 3. 

The best way to learn to use the priority register is to experiment with it.* 
Let's modify our program to do that by making these seven changes: 



*l am deliberately avoiding, here, the usual discussion of "playfields thru 4." That's because it's 
difficult to define how a specific playfield is created using SETCOLOR, COLOR, PLOT, and 
DRAWTO statements. 
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1. Change line 1 so that it reads: 

GOSUB 4000:GOSUB 2000:GOTO 200 

2. Add this subroutine starting at line 4000: 

4000 ? "What number would you like to poke into the 
priority register?":INPUT PR 

4020 RETURN 

3. At line 10050 set the variable PRIOR to 623. 

4. Delete the RETURN statement at line 11095. 

5. Add line 11110 as follows: 

POKE PRIOR, PR 

6. Put a RETURN at line 11299. 

7. Change line 2 to: 

SAVE "D:MOVE2.SAV":STOP 

After making these changes save the program and then run it. Try poking 
different numbers (1,2,4,8) into the priority register. Then move your player in 
front of the different colored playfield objects on the screen. Make a note of the 
results. 

If you're going to take a break, now is a good time. When you come 
back, we'll discuss speed. 

CHANGING SPEED 

In some situations you may want to change the speed of a player. For example, 
in a horse race simulation, you might want to assign different speeds to the 
different horses. In a baseball game, you might want to assign various running 
speeds to different players. To do this all you need to do is set SP to different 
values. 

Experiment with Different Speeds 

To experiment with different speeds, try adding line 4010 as follows: 
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?"ENTER A NUMBER BETWEEN 1.0 AND 2.0 TO SET 
SPEED OF PLAYER. ":INPUT SP:RETURN 

Also, delete SP=1 from line 10050. Then run the program several times, 
setting SP to various numbers from 1.0 to 2.0. When you've got the player's 
speed under your control, continue reading. 



Faster Speeds 

Now try to set the player's speed even faster— to a number greater than 2.0. 

■ What happens when you move the player vertically? Horizontally? 



ANSWER 

Notice that when you move the player vertically, you leave a trail consisting 
of pieces of the player! But when you move him horizontally, this doesn't 
happen. That's because horizontal movement is controlled by poking a 
number into the horizontal position register. Atari then takes care of erasing 
the player and repositioning him horizontally. But for vertical movement 
there is no horizontal position register, yet.* 



To move the player vertically, we have to write the player image data into 
different bytes of the player image string. Consider for a moment the data that 
we put into IMAGE1S: 

0,0,28,28,8,28,58,89,24,40,76,68,68,0,0 

■ Notice that the first two bytes of IMAGE1 S contain zeros. What do the last 
two bytes contain? 



ANSWER 



They contain zeros also. 



*l suspect that when Atari updates its PMG system, a vertical position register wili be added. After 
all, the Commodore 64 has one! In the meantime, we have to manage with other means to move 
our players vertically. 
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These zeros serve the purpose of automatically erasing the player image 
as we move it around within PLAYEROS. Let's look at some specific examples. 
Suppose we position the player near the bottom of the screen at vertical 
position 80. To do this we might use these commands: 

Y0=80: PLAYER0$(Y0)=IMAGE1$ 

The diagram below shows what will be in each byte of PLAYEROS: 

Byte Contents 

1 

2 - 

3 



(and so on) 

80 

81 

82 28 

83 28 

84 8 

85 28 

86 28 

87 89 PLAYER IMAGE DATA 

88 24 

89 40 

90 76 

91 68 

92 68 

93 

94 

Notice that our player image data is located at bytes 80 thru 94. Now 
suppose we want to move our player upward by one byte. To do this we need 
to move all 15 bytes upward. For example, the value 76 in byte 90 will be 
moved up so that byte 89 will contain 76. 



Consider byte 92. Before we move the player, byte 92 contains 68. This is 
the data for the bottom of the player (his feet). When we move the player 
image data up one byte, what will be in byte 92? 
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ANSWER 



A zero! This is important. As we move the player data up, the player erases 
himself. 



Since we have two zeros at the beginning of IMAGE1S and two at the 
end, we can move the data in one or two byte increments and the "trailing 
zeros" will automatically erase the player image. 

■ We can still move the player vertically in three byte increments. But we will 
need to change IMAGE! S, What changes would we need to make? 





ANSWER 




We would need to dimension 


IMAGEIS for 17 bytes. 


Then we would need 


to make bytes 1 -3 and bytes 15 


-17 zeros. IMAGEIS would then contain this 


data: 






0,0,0,28,28,8,28,58,89,24,40,76,68,68,0,0,0 





To make this change, we would need to change line 11300, so the data 
matches that given above. We would also need to change line 11050 so that it 
reads: 

11050 DIM IMAGE$(17) 
And line 1 1 060 should be: 

11060 FOR 1 = 1 TO 17: 
READ A: 

IMAGE1$(I,I)=CHR$(A): 
NEXT I 

Make those changes. Then try setting SP to 3. Your player will now erase 
himself completely as he moves vertically at a speed of 3 bytes per movel 



LOOKING AT PM DATA 

To get a better idea of how PM data is stored in PLAYEROS, try this. Move the 
player to some vertical position of interest. Then press the SYSTEM RESET key. 
Next type in and run the following routine. You can run the routine simply by 
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typing "GOTO 600,'" and pressing RETURN. The routine will show you the 
contents of PLAYEROS byte by byte. To temporarily halt the routine, hold down 
the CONTROL key and press "1." Do the same to restart it. 

600 GR.0:TRAP 610: FOR 1 = 1 to 128: 

? I;" ";ASC (PLAYER0$(l)): 

NEXT l:STOP 
610 END 

Well, we've come a long way. But there is still a lot to learn about PMG! 
For one thing, although our player moves around the screen at our command, 
she looks funny because her legs don't move! In the next chapter you'll learn 
how to fix that. 

For your convenience at the end of this chapter is a complete listing of 
the program. It's set up so you can choose the value to poke into the priority 
register. You can also choose the value for SP, which determines the speed of 
the player. 



1 GOSUB 4000:G0SUB 2000: GOTO 200 

2 SAVE "D:MOVE2.SAV ,, :ST0P : REM DISK 30 



4 REM ADJUST HORIZONTAL & VERTICAL 




COORDINATES 






5 xo=xo+sp: yo=yo+sp: return 






6 yo=yo-sp: xo=xo+sp: return 






7 XO=X0+SP: RETURN 






9 xo=xo-sp: yo=yo+sp: return 






10 xo=xo-sp: yo=yo-sp: return 






ii xo=xo-sp: return 






13 YO=YO+SP: RETURN 






14 YO=YO-SP: RETURN 






15 RETURN 






199 REM MAIN LOOP 






200 GOSUB PEEK (JOYSTICK) : POKE HPOSPO, 


X 


: PLAYERO* ( YO ) = I MAGE 1 * : GOTO 200 






260 REM 






270 REM 






280 REM 






290 REM 






600 GRAPHICS 0:TRAP 610: FOR 1=1 


TO 12 


8 


:? IS" "5 ASC(PLAYERO*(I) ) : NEXT 


I: STOP 
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610 END 

1999 REM SETUP ROUTINES FOLLOW 

2000 GOSUB 1 0000: REM MISC. INITIALI- 
ZATION 

2005 GRAPHICS 5: REM SET GR. MOVE 

BEFORE PMG SETUP' 

2010 GOSUB 1 1000: REM PMG SETUP 

2015 GOSUB 12000: REM BRAN PLAYFIELB 

2020 GOSUB 13000: REM PLAYER COLOR AND 

SCREEN POSITION 

2130 RETURN 

4000 ? "WHAT NUMBER WOULD YOU LIKE TO 

POKE INTO THE PRIORITY REGISTER?": I 

NPUT PR 

4010 ? "WHAT SPEED WOULD YOU LIKE FOR 

THE PLAYER? 1, 2, OR 3?": INPUT SP 

10000 REM MISC. INITIALIZATION 

1 0050 3 OYST I CK=632 : HP0SP0=5324B : PR I OR* 

623: RETURN 

10999 REM PMG SETUP ROUTINE 

11000 DIM FILLER1*(1) , FILLER2*( (INT (AD 
R (FILLER 1$) /1024) +1 ) * 1024- ADR (FILLER 1* 
)-l) 

11010 DIM BUFFER* (384) , MISSILES* (128) , 

PLAYERO* ( 128) , PLAYER1*( 128) , PLAYER2* ( 1 

28) , PLAYER3*(128) 

1 1020 BUFFER*=CHR* (0) 

11030 BUFFER* (384) =CHR*(0) 

11040 buffer* (2) =buffer* 

1 1045 missiles*=buffer*: playero*=buffe 

r*:playeri*=buffer*:player2*=buffer*:p 

layer3*=buffer* 

11050 DIM IMAGE1*(17) 

11060 FOR 1 = 1 TO 17: READ A: I MAGE 1 * ( I , I 

)=CHR*(A) :NEXT I 

11080 POKE 54279, ADR (BUFFER*) /256: REM 

DTELL ANTIC WHERE START OF PM MEMORY I 

S 

11085 POKE 559, 46: REM DOUBLE LINE RES. 

11090 POKE 53277, 3: REM TURN ON PMG 
11110 POKE PRIOR, PR 
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11299 RETURN 

11300 DATA 0,0, 0,28, 28, 8, 28, 58, 89, 24, 4 
0, 76, 68, 68,0,0, 

11999 REM BRAN PLAYFIELB 

12000 BETCOLOR 4, 16, 2: COLOR 1 
12010 PLOT 0,20:DRAWT0 40,20 

12020 COLOR 3-.DRAWT0 60, 35: COLOR 2:DRA 
WTO 79,35 
12030 RETURN 

12999 REM SET PLAYER COLOR ANB 
POSITION 

13000 X0=52 
13010 Y0=12 
13020 POKE 704,88 

13030 POKE 53248, XO: REM POKE HORI- 
ZONTAL VALUE INTO HORIZON! ON AL 
POSITION REGISTER. 

13040 PLAYER0*(Y0)=IMAGE1$:REM PUT 
IMAGE INTO PROPER BYTE OF PLAVERO. YO 
DETERMINES VERTICAL POSITION 
13050 RETURN 



" 



" 




Making Your Player 
Dance 



Next you will learn how to add life to your player by making his or her legs 
move. You'll also be able to create other kinds of movements as desired. In 
addition, you'll learn how to take care of those troublesome errors that occur 
when you move a player too far off the screen. 
Let's start by animating those legs. 



DEFINING IMAGES 



To make our player's legs move, we need to define three player images, which 
we will call "LEGSIS. LEGS2S, and LEGS3S." 

Here's the first image for our player along with the data needed to create 
her. (Notice that we have omitted the leading and trailing zeros.) 
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And here's the second image with accompanying data. 




Now it's your turn. As a review, see if you can calculate the data for this 
third image: 
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ANSWER 



28,28,8.28,58,89,24,56,72,132,130 



INITIALIZING THE IMAGE STRINGS 

Now that we've designed the images, we need to initialize our player image 
strings. Remember how we do it? To initialize our first image, we use a line like 

this: 

11060 FOR 1 = 1 TO 17:READ A: 

LEGS1$(I,I) = CHR$(A):NEXT I 



I The data for this will appear on line N300 like this: 

11300 DATA 0,0.0,28,28,8,28,58,89.24,60,36,36,102,0,0,0 



/ 



\ 



Notice that we added 
three leading zeros. 



And three trailing zeros. 



Why did we do that? 
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ANSWER 

So the player will erase herself when we move her up or down. By using 
three leading and trailing zeros we can bump the player up three bytes 
and still get a clean erase. 



Now to initialize our second image we simply insert line 11065, which is 
almost identical to line 11060: 

11065 FOR 1 = 1 TO 17:READ A: 

LEGS2$(I,I)=CHR$(A):NEXT I 

Of course we also need to add the data for LEGS2S. We do that on line H310: 

11310 DATA 0,0,0,28,28,8,28,58,89, 
24,40,76,68,68,0,0,0 

■ Your turn again. Write the lines needed to initialize the third player image. 
I'll supply the line numbers. 



1 1 067 
ll 320 



ANSWER 



1 1 067 FORM toI7:READA: 
LEGS3S (l,l)=CHRS(A): 
NEXT I 

1 1 320 DATA 0,0,0,28,28,8,28,58.89, 
24,56.72,132,130,0,0,0 



Oh yes, another thing. We need to dimension our new strings. We can 
easily do this on line 11050: 

11050 DIM LEGS1$(17), LEGS2$ (17), LEGS3$(17) 



That takes care of setting up the image strings. Next we need to set up a 
routine to move these images into the PM memory area. Specifically, we 
will want to move them into which string? 
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ANSWER 



We'll want to move the data into PlayerOS, which is the PM memory area 
for PLAYERO. 



AW EXPERIMENT 

First, enter the last program from the previous chapter into memory. Then make 
these changes: 

1. Delete lines 4000 through 4020 and remove GOSUB 4000 from line I. 

2. Change line 11050 so it reads: 

11050 DIM LEGS1$(17), LEGS2$ (17), LEGS3$ (17) 

3. Add lines H060. II 065, and 11067: 

11060 FOR 1 = 1 to 17:READ A: 
LEGS1$ (l,l) = CHR$(A): 
NEXT I 

11065 FOR 1 = 1 to 17:READ A: 
LEGS2$ (l,l)=CHR$(A): 
NEXT I 

11067 FOR 1 = 1 to17:READ A: 
LEGS3$ (l,l) = CHR$(A): 
NEXT I 

4. Add these data lines: 

11300 DATA 0,0,0,28,28,8,28,58,89, 
24,60,36,36,102,0,0,0 

11310 DATA 0,0,0,28,28,8,28,58,89, 
24,40,76,68,68,0,0,0 

11320 DATA 0,0,0,28,28,8,28,58,89, 
24,56,72,132,130,0,0,0 
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5. Change line 200 so it reads like this: 

GOSUB PEEK(JOYSTICK): 
GOSUB MOVELEGS:GOTO 200 

6. Insert at line 10050: 

MOVELEGS=30: 

SP=1: 

PR=8 

7. Add a subroutine at line 30 as follows: 

30 POKE HPOSP0, X0: 
PLAYER0$(Y0) = LEGS1$: 
PLAYER0$(Y0) = LEGS2$: 

31 PLAYER0$(Y0) = LEGS3$: 
RETURN 

8. Change line 13040 so it reads: 
PLAYER0$(Y0) = LEGS1$ 



Notice that we are now moving each of the three images, in turn, into 
the PM memory area. 

■ Before you run the revised program, write down a prediction as to how it 
will turn out. Then try it. What's the result? 



ANSWER 

(I trust you have tried the experiment by now. If you haven't you might 
want to do that now. You'll learn more that way, honest.) Well, the player's 
legs are moving all right, but they're moving too fasti We need to slow 
them down. First, delete lines 30 and 31 and I'll show you how. 



One way is to set up a counter. We'll use the variable Z for this. To 
increment the counter we simply put the statement "Z=Z+1" at the beginning of 
line 30. 

Remember that our animation routine is based on a loop. Each time we 
pass through the loop, variable Z will be increased by one. Also, our player will 
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be moved to a new position based on the new horizontal and vertical coordi- 
nates. Suppose we want the first image to be displayed during the first three 
times through the animation loop. Then we might use an IF-statement at the 
end of line 30. Line 30 would then look like this: 

Z=Z+1:POKE HPOSP0.X0: 

IF Z<4 THEN PLAYER0$(Y0) = LEGS1$: 

RETURN 

Notice the "RETURN" statement that sends control back to the main loop at 
line 200. 

■ Suppose we want image two to be displayed during loop passes 4 
through 6. Code the two statements needed to make that happen. Use 
line 31. 



ANSWER 

31 IF Z<7 THEN PLAYER0S(Y0)=LEGS2S 
RETURN 



Following the same pattern, we might want to display image three 
during loops 7 through 9. We don't need an IF-statement this time. If Z is 7 or 
greater, control will simply pass to line 32. At line 32 we simply set PLAYEROS to 
the third image. However, when X=9, we will want to reset Z to so that next 
time image one will be displayed. 

■ See if you can code the statements for line 32. 



ANSWER 



Here's how I did it: 

32 PLAYER0$(Y0)=LEGS3$: 
IFZ=9THEN Z=0: 
RETURN 



We need to add a statement on line 33 before this routine will work. See if 
you can figure out what it is. Here's a hint. What happens if X=7? Control 
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will pass to line 32, and the third image will be moved into PLAYEROS. But 
since Z is not equal to 9 . . . what will happen? 



ANSWER 

Since Z is not equal to 9. control will pass to the next statement, whatever 
it may happen to be, and we will never return from the subroutine. This 
will lead to problems! Consequently, line 33 needs to be "RETURN" so that 
control will return to the main loop. 



Try it. Make sure lines 30 through 33 read like this: 

30 Z=Z+1:POKE HPOSPO.XO: 

IF Z<4 THEN PLAYER0$(Y0) = LEGS1$: 
RETURN 

31 IFZ<7THEN PLAYER0$(Y0) = LEGS2$: 
RETURN 

32 PLAYER0$(Y0) = LEGS3$: 
IFX=9THEN X=0: 
RETURN 

33 RETURN 

Try this out. What additional problem is there? 



ANSWER 

The player's legs move even when he is standing still! Fortunately, this is 
easy to fix. Just change line 15 to read: 

15 POP:PLAYER0$(Y0)=LEGS1$:GOTO 200 



Control is passed to line 1 5 when the joystick is not moved — when the 
player is stationary. So we can use this line to display a single image and then 
jump back to line 200. The POP command serves to cancel the GOSUB that 
passed control to line 15. By using "POP" we make it "legal" to use the "GOTO 
200" statement. Without the POP statement, you would eventually end up 
with an error message as a result of "GOTO 200." That's because BASIC is set 
up to expect a RETURN statement at the end of a subroutine. 



Trapping Errors / 73 

Try adding line 15. If everything goes well, you will find that the player's 
legs move only when you move the joystick! If you want, you can experiment 
with a different "standing still" image of the player. For example, you might 
code line 15 like this: 

15 POP:PLAYER0$(Y0) = LEGS2$:GOTO 200 

With this statement, image 2 will be displayed when you leave the joystick in 
the upright position. The program will now work fine. If yours doesn't, you may 
wish to compare it with the listing at the end of this chapter. 



TRAPPING ERRORS 

I promised you I'd explain how to handle those error messages that pop up 
when you move the player too far off the screen. Here's one simple way: 

1. Change line l so it reads like this: 

1 TRAP 3000:GOSUB 2000:GOTO 200 

2. Add line 3000: 

3000 PLAYER0$=BUFFER$:Y0=128: 

X0=80:Z=0:TRAP 3000:GOTO 200 

The TRAP at line l says, "Trap any error you find. Don't print an error message. 
Instead, just GOTO line 3000. 

■ What do you think line 3000 says? 



ANSWER 

Erase the player image from the screen. (BUFFERS is set to zeros, so setting 
PLAYER0S equal to BUFFERS is the same as setting PLAYER0 to zeros. That, 
in effect, erases the PLAYERS image.) 



After that, the variables Y0 and X0 are set to some specific values. The 
value of 128 for Y0 hides the player off the bottom of the screen. The value 80 
for X0 puts the PLAYERS at the left of the center of the screen. The result is that if 
you move the player too far off the screen in any direction, she will be automat- 
ically repositioned off the bottom of the screen on the left side. To bring her 
back, just push forward on the joystick and she will scoot up onto the screen. 
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The idea here is that the error condition is caused by a bad value in either 
XO or YO. To fix that, we simply trap the error and reset XO and YO to any desired 
"legal" values. In addition, we reset the leg movement counter (Z) to zero. 

Also, notice that we repeat the TRAP command at line 3000, so that if 
another error occurs, we will again branch to line 3000. (A TRAP statement 
must be reset after an error occurs.) 

If you haven't yet got your player's legs to move, now's the time. You may 
wish to refer to the following program, which is a complete listing of all the 
lines needed to make your player dance! 

Once you have it working, you may wish to animate your player in other 
ways. For example, you might want to add some additional images to make 
the legs move more smoothly — or you may wish to have the player move her 
arms or other body parts. Have fun! 



1 trap 3000:gosub 2000: goto 200 

2 save "d: legs. sav": stop :rem disk 30 

4 rem adjust horizontal & vertical co- 

ordinates 

5 xo=xo+sp: yo=yo+sp: return 

6 yo*yo-sp: xo=xo+sp: return 

7 xo=xo+sp: return 

9 xo=xo-sp: yo=yo+sp: return 

10 xo=xo-sp: yo=yo-sp: return 
ii xo=xo-sp: return 

13 yo-yo+bp: return 

14 yo=yo-sp: return 

15 pop :playero*<yo)=legsi*:goto 200 

29 rem move player's legs 

30 z = z + l:poke hposf'o, xo: if z<4 then pl 
ayero*(yo)=legsl*: return 

31 IF Z<7 THEN PLAYERO* (YO) =LEGS2«: RET 
URN 

32 PLAYERO* (Y0)=LEGS3*: IF Z=9 THEN Z=0 
: RETURN 

33 RETURN 

199 REM MAIN LOOP 

200 GOSUB PEEK (JOYSTICK) : GOSUB MOVELEG 
S:GOTO 200 

260 REM 
270 REM 
280 REM 
290 REM 
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600 GRAPHICS 0:TRAP 610: FOR 1 = 1 TO 12(3 

:? is" "; ASC(PLAYER0*(i) ) :next i: stop 

610 END 

1999 REM SETUP ROUTINES FOLLOW: 

2000 SOSUB 1 0000: REM MISC. INITIALI- 
ZATION 

2005 GRAPHICS 5: REM S£7 GR. NODE 

BEFORE PMG SETUP/ 

2010 GOSUB I 1000: REM PMG SETUP 

2015 GOSUB 12000: REM DRAM PL AY FIELD 

2020 GOSUB 13000: REM PLAYER COLOR AND 

SCREEN POSITION 

2130 RETURN 

2999 REM ERROR CORRECTION ROUTINE 

3000 PLAYERO*=BUFFER*: Y0=128: X0=80: Z=0 
: TRAP 3000: GOTO 200 

10000 REM MISC. INITIALIZATION 

1 0050 JOYST I CK=632 : HP0SP0=5324S : PR I 0R= 

623 : MO VELEGS=30 : SF - 1 : PR=8 : RETURN 

10999 REM PMG SETUP ROUTINE 

11000 DIM FILLER1*< 1) ,FILLER2*( (INT (AD 
R ( F I LLER 1 $ ) / 1 024 ) + 1 ) * 1 024-ADR ( F I LLER 1 * 
)-l) 

11010 DIM BUFFER* (384) , MISSILES* ( 128) , 

PLAYERO* ( 128) , PLAYER 1* ( 128) , PLAYER2* ( 1 

28) ,PLAYER3*(128) 

1 1 020 BUFFER*=CHR* ( ) 

11030 BUFFER* (384) =CHR*(0> 

1 1 040 BUFFER* ( 2 ) =BUFFER* 

1 1 045 M I SS I LES*=BUFFER* : PL A YERO*=BUFFE 

R*: PLAYER1*=BUFFER*: PLAYER2*=BUFFER*: P 

LAYER3*=BUFFER* 

11050 DIM LEGS1*(17) ,LEGS2*(17) , LEGS3* 

(17) 

11060 FOR 1=1 TO 17:READ A: LEGS1* ( I , I ) 

=CHR*(A) :NEXT I 

11065 FOR 1=1 TO 17: READ A: LEGS2* ( I , I ) 

=CHR*(A) :NEXT I 

11067 FOR 1=1 TO 17: READ A: LEGS3* ( I , I ) 

=CHR*(A) :NEXT I 

11080 POKE 54279, ADR (BUFFER*) /256: REM 

DTELL ANTIC WHERE START OF PM MEMORY I 

S 
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11085 POKE 559 ,46: REM DOUBLE LINE RES. 

11090 POKE 53277, 3: REM TURN ON PMG 
11110 POKE PRIOR, PR 

11299 RETURN 

11300 DATA 0,0,0,28,28,8,28,58,89,24,6 
0,36,36, 102, O, 0, 

11310 DATA 0,0,0,28,28,8,28,58,89,24,4 

0,76,68,68,0,0,0 

11320 DATA 0,0,0,28,28,8,28,58,89,24,5 

6,72, 132, 130, 0,0,0 

11999 REM BRAN PLGYFIELT) 

12000 SETCOLOR 4, 16, 2: COLOR 1 
12010 PLOT 0,20:DRAWT0 40,20 

12020 COLOR 3:DRAWT0 60, 35: COLOR 2:DRA 
WTO 79,35 
12030 RETURN 

12999 REM SET PLOVER COLOR f)HB 
POSITION 

13000 X0=52 
13010 Y0=12 
13020 POKE 704,88 

13030 POKE 53248, XO: REM POKE HORIZON- 
TAL VALUE INTO HORIZON! ONAL POSITION 
REGISTER. 

13040 PLAYER0*(Y0)=LEBS1$:REM PUT 
IMAGE INTO PROPER BYTE OF PLAYERO. 
13050 RETURN 




Adding Sound 



Now that you have your player dancing around the screen, let's add some 
sound effects! They can help to make an exciting animation sequence even 
better. 

When you finish this chapter you'll be able to create some interesting 
sound effects to go along with the movement of your players. In addition, 
you'll learn how to maximize the execution speed of these sound routines. 

I'm going to begin with a brief discussion of the SOUND statement. If 
you're already an expert on this, you may wish to skip ahead to "Chords" in this 
chapter. Otherwise, read on. 



THE SOUND STATEMENT 

Most Atari BASIC programs use the SOUND statement. It's a powerful state- 
ment because it enables you to control the pitch, distortion, and volume for 
each of four "voices." 

Yes, Atari has four voices. Before we get into the details of the SOUND 
statement, let's consider what is meant by the term "voice." Think of a four- 
voice choir. In such a choir there are four separate groups of singers. Each 



77 



78 / Adding Sound 

group [or "voice") usually sings a separate melody (series of notes). Here are 
the names and ranges of the different voices in a four-voice choir: 



Name of Voice 


Range 


Soprano 


(Usually sings highest notes 


Alto 


(Next to the highest notes) 


Tenor 


(Next to the lowest notes) 


Bass 


(Lowest notes) 



Now back to the SOUND statement. In Atari BASIC the names of the four 
voices are 0, 1, 2, 3. (Again, notice that we start counting with "0" rather than 
"1.") Here's how you specify the voice, pitch, distortion, and loudness with a 
sound statement: 

SOUND VOICE, PITCH, DISTORTION,VOLUME 

"SOUND" is a key word such as "GOTO." The other items ("VOICE." 
"PITCH," "DISTORTION," and "VOLUME") are called parameters. Let's call 
them "parms" for short. In the above example they are variables. Before 
executing the above statement, you would need to set these variables to 
appropriate values. 

Alternatively, you could use fixed numerical values (constants) or arithme- 
tic expressions in place of those variables. For example, you might write: 

SOUND 0,121,10,8 or SOUND 0,5*20+1,10,8 

Both statements would cause voice to play the note called "Middle C" since 
a value of !2l="Middle C." (See page 58 in your ARARI BASIC REFERENCE 
MANUAL for numbers corresponding to the various musical pitches.) 

The "10" in the above statement (the third parm) creates a "pure tone"— 
one with no distortion. Instead of "10," you can use other even numbers 
between and 14 for various sound effects. 

The fourth parm tells Atari how loud you want the sound to be. This 
value can be between 1 and 15. The higher the number, the louder the sound. 

Before we go any further, let's experiment with a few simple SOUND 
statements. Get your Atari up and running. Then type in this next command 
just like it is — without a line number: 

SOUND 0,121,10,8 

■ When you press RETURN the command will immediately execute. What 
note will you hear? 
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ANSWER 



Middle C. (121 is the value for Middle C. remember.) 



Try it. Then enter this command: 
STOP 

What happened? 









ANSWER 






Nothing really, 
on a SOUND 
command. Try 


The sound 
command, 
it. 


will 
To 


continue. The STOP command has no 
turn off the sound, simply enter the 


effect 
END 



The END command can come in handy when you decide you want 
some peace and quiet for a change. 



Experiment 

Move the cursor back up to the SOUND command you entered earlier. (To 
move the cursor, hold down the CTRL key while pressing the arrow keys.) Try 
changing the distortion parameter (the third one). Enter various even numbers 
from Oto 14. If you hear an effect you like, you may wish to make a note of the 
SOUND parms. In the same way, experiment with the volume parm by enter- 
ing various numbers from 1 to 15. 



CHORDS 

A chord is a combination of musical pitches. It's easy to make chords with the 
Atari. You simple turn on more than one voice. Try this example. It will produce 
what musician's call a C-major chord: 

SOUND 0,243,10,8 
SOUND 1,121,10,8 
SOUND 2,96,10,8 
SOUND 3,81,10,8 
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One caution: if the total of all the volume parms exceeds 32, an un- 
pleasant "clipped" tone will result. 

■ In the example above, did I observe this caution? What is the total of the 
volume parameters in the example? 



ANSWER 

Yes. The volume parms add up to exactly 32 (8+8+8+8=32). 



POKING SOUND PARMS 

Because of its ease of use, you may choose to use the SOUND command in 
your programs. But if you are coding an animation sequence for, say, a game or 
other simulation, then it may be better to poke sound parms directly into 
memory. SOUND statements execute more slowly than direct pokes. 

Here's how you poke sound parms. To set the pitch of voice 0, simply 
poke a number into memory location 53760. To set the distortion and volume, 
first multiply the desired distortion number by 16 and add it to the value for 
volume. Then poke this one number into 53261. 

For example, instead of writing SOUND 0,121,10,8, you would write: 

POKE 53760,121 
POKE 53761,168 



(We poked 168 into 53761 because 16*10+8=168.) 

■ Now you try it. What POKE commands would be needed to replace this 
SOUND command? 

SOUND 0,96,5,5 





ANSWER 




POKE 53760,96 






POKE 53761 ,85 (since 


5*16+5=85) 




(Try these out. Enter them 


directly without I 


ne numbers.) 



■ 
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SOUND REGISTERS 



So far I've shown you only two sound control registers: 53760 and 53761. Here 
is a more complete list: 



Location 


Used to Control 


53760 


Pitch of voice 


53761 


Distortion and volume of voice 


53762 


Pitch of voice 1 


53763 


Distortion and volume of voice 1 


53764 


Pitch of voice 2 


53765 


Distortion and volume of voice 2 


53766 


Pitch of voice 3 


53767 


Distortion and volume of voice 3 


53768 


Pitch of all voices 



(More on this later) 

Look over these locations for a moment. What do the even numbered 
locations all control? The odd ones? 



ANSWER 

The even numbered locations all control pitch. The odd ones control distor- 
tion and volume. 



MORE EXPERIMENTS 

Now let's try some more experiments. Type in and try out this little sound demo 
program. Then read on. 



4 GOTO 10 

5 SAVE "DrGLODE. SAV" : STOP 
10 BOSUB "IOOO 

20 TRAP 20::? CHR*(125):? :? :? "ENTER 

GLIDING SPEED (1-255) "?: INPUT ST 

30 ? :? "ENTER DISTORTION (EVEN NUMBER 

PROM 0-14) "5: INPUT DIST 
35 D0=16*DIST+V0L 
50 FOR PO=l TO 255 STEP ST 
60 POKE S0„R0 
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70 POKE- DVO,D0 




80 NEXT PO 




90 POKE DVOjO 




100 SOTO 20 




999 END 




1 S - 5 3 7 6 : D V = 5376 1 : 5 1 :: 


=53762:091=5 


3763:S2==53764SDV2=53765:S3= 


=53766:093=5 


3767:90L=8 




1100 RETURN 





Notes on the Sound Demo 

Line 60: POKE SO,PO This is where I specify what pitch to make the sound. 
SO is the pitch control register for voice 0. (I initialized SO to 53760 in the 
subroutine at line 1000.) PO will be some value between 1 and 255. That's 
because you are asked to enter such a number at line 20. 

Line 70: POKE DV0,D0 Here I turn on the distortion and volume of voice 0. 
(I initialized DVO to 53762 in line 1000. 53762 is the distortion and volume 
control register for voice 0.) The value contained in DO was calculated on line 
35. 

Line 35 D0=16*DIST+VOL Here I set DO to the value that is derived from the 
desired distortion and volume. As I mentioned earlier, we do this by first 
multiplying the desired distortion by 16 and then adding the desired volume. 
You'll notice that DIST is set at line 30 in response to the prompt "ENTER 
DISTORTION." I initialized VOL to 8 in line 1000. 1 could have set it to any value 
from to 15. 



50 FOR P0=1 TO 255 STEP ST This is the beginning of a FOR/NEXT loop. 
Note the part that says "STEP ST." This command tells the computer how much 
to increment PO at each pass through the loop. ST is set at line 30 in response to 
the prompt "ENTER GLIDING SPEED." If ST is set to, say, 5 then PO will be set to 
1 the first time through the loop, but 6 the second time (since 1+5=6). 

■ Suppose we set ST to 20. What will PO egual on the second pass through 
the loop? 
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ANSWER 

21 (1+20) 



So the higher the value of ST, the bigger change in P0 at each pass 
through the loop. When ST is set to, say, 1, there will be a slow, smooth gliding 
pitch, when ST is set to progressively higher values, the sound changes in pitch 
rapidly and has a shorter duration (since it takes fewer times through the loop 
to reach 255). 

Line 90: POKE DV0,0 This simply turns off the volume for voice 0. I do this 
so that the sound stops when control returns to the initial prompt at line 20. 1 
could also have turned off the sound by poking a into DO. 

Experiment 

If you haven't already done so, I suggest you try experimenting with different 
values for distortion (DIST) and gliding speed (ST). 

Also, you might want to modify the program to make it easier to hear the 
various sounds being produced. For example you might put a delay on the 
FOR/NEXT loop. You could do this by adding this line to the program: 

75 FOR PAUSE=1 to 100:NEXT PAUSE 

Another idea would be to print the value of P0 on the screen so you 
could observe the values being poked into SO. 



USING A LOOP 

Notice how I produced a gliding effect by putting the poke statements inside of 
a loop. In the same way you can put these poke statements within your 
animation loop. This way, you get a kind of gliding effect as your player or 
missile moves around the screen. 

Assignment 

Let's try this with the moving legs routine we developed in the last chapter. 
What we will do is create some interesting "traveling sounds" for our player. 
Whenever the player moves we'll play some sounds. When the player stops, 
the sound will stop. 
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Perhaps you have some ideas about how this might be done. If so, you 
might want to experiment on your own before continuing. 

Traveling Sounds 

Take a look at the program you entered in the previous chapter (which I called 
"LEGS.SAV"). One approach to making traveling sounds might be to add a 
"sound statement" to the "MOVELEGS" subroutine, which begins at line 30. 

A simple way to do this would be to use the variable Z to set the pitch of 
the sound. As you will recall we used Z as a counter to control the display of 
various running images of our player. When Z was less than 4, we displayed 
"LEG1S". When Z was in the range of 4 through 6, we displayed "LEG2S," and 
so on. We added 1 to Z at the beginning of the MOVELEGS routine so that 
each time the routine was called, Z was greater than before. When Z reached 9, 
it was reset to 0. 

Well, we can make Z do double work. Here's how we might do it with a 
sound statement: 

SOUND0,Z,10,8 

■ Based on what I've said so far, at what line might you insert this sound 
statement? What would the revised line look like? 



ANSWER 




You might insert the statement into line 30, 


like this: 


30Z=Z+1:SOUND0,Z,10,8: 






IF Z<4 THEN PLAYER0$(Y0) 


=LEGS1$:RETURN 



Before you continue reading, you might want to revise the "LEGS' 
program by changing line 30 as we've just discussed. 



USING POKES 

Suppose you were to use Poke statements to create the sound. First, you might 
initialize these variables: 

S0=53760 
DV053761 
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What would SO stand for? DVO? 



ANSWER 






SO would stand for the pitch control register 


for voice 0. 


DVO would stand 


for the distortion/volume control register for 


voice 0. 





What would line 30 look like if you used Poke statements to create sound? 



ANSWER 

30Z=Z+1:POKES0,Z:POKE DVO, 168: 
IFZ<4THEN PLAYER0$(Y0) = LEGS1$ 
RETURN 



(Recall that to find the proper value for a distortion of 1 and a volume of 
8, we multiply 16 times the distortion. This gives us 160. We then add the 
volume (8) to 160 to arrive at the DVO value of 168.) 



ADDING VARIETY 

To give more variety to the sound, you might consider multiplying Z by some 
number. For example: 

POKE S0,Z*TONE:POKE DVO 

With this code, different sounds will be produced depending on the value of 
TONE. For example if TONE=20 then the first time through the loop ZTONE 
will equal 20; the second, 40; the third 60; and so on. The bigger the value in 
TONE the bigger the jump in pitch that will occur on each pass through the 
MOVELEGS routine. 

At the end of this chapter is a program that will let you experiment with 
different "traveling sounds" for your player. It is similar to the LEGS program 
from the previous chapter. I have circled lines that need to be added or 
changed. 

As you will probably notice, the addition of sound to the program slows 
down the player somewhat. That's one of the trade-offs. The more features you 
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add— like sound, missile firing, collision detection, and so on, the bigger your 
loop becomes and the slower the animation. That's why I've stressed tech- 
nigues that will help you maximize execution speed— such as poking values 
into sound registers and placing frequently executed code early in the program. 
Of course, machine language is probably the best— although the hardest- 
way to obtain fast player/missile action.* 

Well, speaking of missiles, in our next chapter let's take a look at what 
they are and how to use them. 

1 60SUB 2000: GOTO 200 

2 SAVE M D:SOUNDRUN.SAV":STOP : REM BISK 
30 

4 rem adjust horizontal & vertical 
coordinates 

5 x0=x0+sp: y0=y0+sp: return 

6 y0=y0-sp: x0=x0+sp: return 

7 xo=xo+sp: return 

9 xo=xo-sp: yo=yo+sp: return 

10 xo=xo-sp: yo=yo-sp: return 
u xo=xo-sp: return 

13 yo=yo+sp: return 

14 yo=yo-sp: return _____ 

15 pop :playero*(YO>=legsi*:(poke dvoTo) 
:G0T0 200 

29 REM MOUE PLAYERS LEGi 



30 z=z+i:( p5ke so, z*tqne:pdke dvo,dq) pq 
ke hpospo, xo: if z<4 then playero* (y0> = 
legs 1*: return 

31 if z<7 then playero* (yo) =legs2«: ret 

URN 

32 PLAYERO* <Y0)=LEGS3*: IF Z=9 THEN Z=0 
: RETURN 

33 RETURN 

199 REM MAIN LOOP 



200 IF PEEK. (BUTTQNO)=0 THEN GOSUB SETS 
OUND 

204 GOSUB P EEK (JOYSTICK) : GOSUB MOVELEG 
.5: GOTO 200/ ' 
260 REM 
270 REM 
2S0 REM 



"When you're ready to dirty your hands with machine language, look for my new book on Player 
Missile Graphics in Assembly Language. 
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290 REM 

600 GRAPHICS 0:TRAP 610: FOR 1=1 TO 128 

:? IS" "S ASC(PLAYERO*(I) ) : NEXT I : STOP 



610 END 









1000 poke dv0,0:? :? "enter distortion 
number (0-14) "s: input dist:? "enter 
tone number (1-28) ";: input tone 
1010 ? "enter volume number (0-15) ";: 
input vol:do=dist*16+vol:rem do mill 
be poked into distortion/vol. register 



1015 ? CHR*(125) :POKE 75 
he fire button to change 

020_ RETURN 

1999 



!,0:? "Press 
sound . " 



t 



REM SETUP ROUTINES FOLLOW- 
GOSUB 1 0000: REM MISC. INITIALIZA- 



GR. MODE 



2000 

TION 

2005 GRAPHICS 5: REM SET 

BEFORE PMG SETUP/ 

2010 GOSUB 1 1000." REM PMG SETUP 

2015 GOSUB 12000: REM DRAM PL AY FIELD 

2020 GOSUB 13000: REM PLAYER COLOR AND 

SCREEN POSITION 



a 



025 GOSUB 14000: REM DISPLAY 



LAY MESSAGE^ 



2130 RETURN 

2999 rem error correction routine 

3000 playero*=buffer*: y0=128: x0=80: z = 
:trap 3000: goto 200 

10000 rem misc. initialization 



■0 



10050 JDYSTICK=632 : HP0SP0=53248 : PR 1 0R= 
623: M0VELEGS=30: SP=1 : PR=8: BUTT0N0=644: 

;ETSQUNP= 1 OOP : S0=53760 ±Z 

1 0060 BUTT0N0=644 : SETS0UND= 1 000 : 30=537 
60: DV0=53761 : RETURN 



10999 REM PMG SETUP ROUTINE 

11000 DIM FILLER1*(1) ,FILLER2*( (I NT (AD 
R ( F I LLER 1 * ) / 1 024 ) + 1 ) * 1 024- ADR ( F I LLER 1 * 
)--l) 

11010 DIM BUFFER* (384) , MISSILES* (128) , 

PLAYERO* ( 1 28 ) , PLAYER 1 * ( 1 28 ) , PLAYER2* ( 1 

28) , PLAYER3*(128) 

1 1 020 BUFFER*=CHR* ( ) 

11030 BUFFER* (384) =CHR*(0) 

1 1 040 BUFFER* ( 2 ) =BUFFER* 
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1 1 045 MISS I LES$=BUFFER* : FLAYERO*=BUFFE 

R*: PLAYER 1*=BUFFER*: PLAYER2*=BUFFER*: P 

LAYER3*=BUFFER* 

11050 DIM LEGS1$<17) , LEGS2* < 17) , LEGS3* 

(17) 

11060 FOR 1=1 TO 17: READ A: LEQS1* ( I , I ) 

=CHRS(A) :NEXT I 

11065 FOR 1=1 TD 17: READ A: LEGS2* ( I , I ) 

=CHR*(A) :NEXT I 

11067 FOR 1=1 TO 17: READ A: LEGS3* ( I , I ) 

=CHR*(A) :NEXT I 

11080 POKE 54279, ADR (BUFFER*) /256: REM 

DTELL ANTIC WHERE START OF PM MEMORY I 

S 

11085 POKE 559, 46: REM DOUBLE LINE RES. 

11090 POKE 53277, 3: REM TURN ON PMG 
11110 POKE PRIOR, PR 

11299 RETURN 

11300 DATA 0,0,0,28,28,8,28,58,89,24,6 
0, 36, 36, 102, 0,0, 

11310 DATA 0,0,0,28,28,8,28,58,89,24,4 
0, 76, 68, 68, 0, 0, 

11320 DATA 0,0,0,28,28,8,28,58,89,24,5 
6,72, 132, 130,0,0,0 

11999 REM BRAN PLAYFIELD 

12000 SETCOLOR 4, 16, 2: COLOR 1 
1 20 1 PLOT , 20 : DRAWTO 40 , 20 

12020 COLOR 3." DRAWTO 60, 35: COLOR 2:DRA 
WTO 79,35 
12030 RETURN 

12999 REM SET PLAYER COLOR AND 
POSITION 

13000 X0=52 
13010 Y0=12 
13020 POKE 704,88 

13030 POKE 53248, XO: REM POKE 
HORIZONTAL VALUE INTO HORIZONTONAL 
POSITION REGISTER. 

13040 PLAYER0$(Y0)=LEGS1*:REM PUT 
IMAGE INTO PROPER BYTE OF PLAYERO. 
13050 RETURN 



cs 



14000 ? "To create sound, push fir 
tton. "; : RETURN 



:3 




Missiles 



As I mentioned earlier, Atari Player-Missile Graphics was originally designed to 
simplify the creation of arcade-style games. These games often include little 
creatures who fire missiles (or bullets) at each other. In this chapter you'll learn 
to create and animate these missiles. Keep in mind that missiles can also serve 
other purposes: they can highlight text in graphics mode 0, for example. 



DEFINING THE MISSILE IMAGE 

There are four missiles available in PMG. All four missiles are stored in a single 
byte in "missile memory." 

■ How many bits wide is a single missile? (Keep in mind that a byte is made 
up of eight bits.) 





ANSWER 












Each missile 


is two bits wide (in contrast to 


players. 


which 


are 


eight 


bits 


wide). 















89 
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Let's look at a map of a single byte of the missile memory area: 
C1283 C643 C32J £163 C8> C4> C23 C13 



O0O0OOOO 



MISSILE 3 



MISSILE 2 MISSILE 1 



MISSILE 



Since this byte has nothing but zeros in it, no missiles would appear on 
the screen. Now if we wanted to make missile I appear on the screen, we 
might put this binary data into a byte of missile memory: 

C128) C64J C32J C16) C8) C4) C2) £11 



00001100 



MISSILE 1 

What would be the decimal number needed to turn on missile I? (Re- 
member how we calculated those decimal numbers for players? We do 
the same thing with missiles. The bit on the far right is worth l; the next bit 
to the left is worth 2; the next bit to the left, 4; and so on. Each successive 
bit to the left is worth twice as much as the previous bit.) 



ANSWER 

We need a decimal 12 to create the necessary binary data in missile mem- 
ory since a binary 00001100 = a decimal 12. 



If we wanted a thinner missile I, what binary data might we use? 



ANSWER 



We could use either 00000100 or 0000\000. 
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So if we wanted a thin missile I, we might use a decimal 4 or 8 to put the 
proper binary data into missile memory. 

■ Ok, try this one. What binary number would you use to turn on missile 
so that it has full width? What would the corresponding decimal number 
be? 

Binary Number: 
Decimal Number: 



ANSWER 



The binary number would be 00000011: the decimal number, 3. 



Suppose you wanted to turn on both bits of missiles and 1 . What binary 
number would you need? Decimal number? 

Binary Number: 

Decimal Number: 



ANSWER 



You'd need a binary 00001 1 1 1 or a decimal 15. 



Ok, so let's say we want to turn on both bits of missile 0. We know that 
we need to put a 3 into missile memory to do this since a binary 0000001 1 = 3. 
But what specifically do we do to code this? 



Image String 

It's fairly simple. We just create an "image string" similar to the strings we 
defined earlier. For a missile, a single byte string may be enough. Remember, 
the more bytes in your image string, the taller the player or missile will be. 

Once we have the data in the image string we can easily zap it into the 
missile memory area at machine language speed. This only works, of course, 
because we have carefully defined our PMG area with strings. 
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■ Let's call our missile image string MIMAGES. We need to do two things to 
set up MIMAGES; dimension it and then plug in a decimal 3. See if you can 
write the code to do it. (It will go into your new program as line 11070.) 



ANSWER 

Here's one way: 

11070 DIM MIMAGE0$(1):MIMAGE0$=CHR$(3) 

(I suggest you enter SOUNDRUN. SAV— the program from the previous 
chapter— and add the new statements as you read along.) 



HORIZONTAL POSITION REGISTER 

Let's initialize another variable for the horizontal position register for missile 0. 
We'll call it HPOSM0. So at line 10060, we add this statement: 

HPOMS0=53252 

(Note that HPOSM0 ends with a zero, not the letter "O.") 

Another minor change to make in SOUNDRUN is the automatic save 
routine at line 2. Change it to: 

2 SAVE "D:MISSILE.SAV":STOP 

That way you won't wipe out the previous program when you save this one. 

REVISING THE MAIN LOOP 

Since we will be using the joystick button to fire missiles, we need to delete line 
200 from the SOUNDRUN program. After deleting line 200, renumber line 204 
so that it now becomes 200. Line 200 will now read: 

200 GOSUB PEEK (JOYSTICK):GOSUB MOVELEGS: 
GOTO 200 

Also, let's delete these pokes from line 30: 

POKES0,X*TONE 
POKE DV0,D0 

since we won't be including player traveling sounds this time. 
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In a moment we are going to add a routine to move our missile. We want 
line 200 to fall through to this new routine. So what change do we need 
to make to our new line 200 shown above? 





ANSWER 








We need to delete GOTO 200 


otherwise control 


will not fall 


through 


to 


our new routine. 











BUILDING A MISSILE MOVE ROUTINE 






As you know, we have set up our player move routine so that our player can 
move in any one of the eight joystick directions (up, down, left, right, plus the 
four diagonal directions). Wouldn't it be nice if our player could also fire a 
missile in any one of those directions? 

To make this work, let's make a rule that a player must be moving when 
she fires a missile. Furthermore, the missile will go in the same direction as the 
player. Now, how do we write the code to accomplish this? 

First, we need to identify when the fire button is pressed while the stick is 
also being deflected from its upright position. If that happens, we will set a 
variable called MOVE0 to the stick value. For example, if the stick is moved to 
the left while the fire button is pressed, we will set MCVE0 to 11. (The stick 
value for left is 11.) Also we will increment an "indicator" — a variable that we 
will call FIRE0. This variable will help the routine remember that the joystick 
was pressed. Also, it will serve as a counter. It will count the number of passes 
that have been made through the missile move routine. We need this because 
we need to do different things on the first pass through the loop than on 
successive passes. 



Got all that? See if you can write the code for it. 






ANSWER 



Here's how I did it: 
IF PEEK(BUTTON)=0 AND 
PEEK(JOYSTICK)<>15 
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THEN 




MOVEO 


= PEEK(JOYSTICK): 


FIRE0= 


FiREO+1 



Of course, Atari won't pay any attention to this fancy indentation. But it 
does make it easier to read. It's also easier for me to type on my ATARI TEXT 
WIZARD. This will be line 301. (Yes, there is a line 300. But it will come later. For 
nowjust put a REM at line 300.) 

Next, we need to be able to jump out of this loop if the fire button was 
not pressed. We can't just peek at BUTTON0 to decide whether to leave the 
missile routine because BUTTON0 will return to zero as soon as the button is 
released.* If we relied on BUTTON0, then on the second pass through the loop 
our missile would stop. 

So we look at FIREO. If it equals then we know we need to return to line 
200. The code would then be: 

305 IF FIRE0=0 THEN GOTO 200 

Positioning the Missile 

The first time through the missile move routine, we need to plop the missile 
down on the screen "underneath" our player so that when the missile is 
moved on subsequent passes through the loop, the missile will appear to be 
coming from him. 

■ How does the routine detect the first pass? 



ANSWER 

With a statement such as IF FIRE0=l THEN. 



On first pass through the missile move routine we will also want to: 

• Set DIR0 to a number representing the direction we want the missile to 
move. (Again that will be the familiarjoystick value such as 7 for right, 
14 for up, and so on.) 

• Add 1 to FIREO so that on the next pass through the loop FIREO will be 
greater than 1. 



"Technical note: there is a way to "latch" the fire button so that location 644 is not reset as soon as 
the button is released. I find it easier to use this method, however. 
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Consider for a moment what the code might look like for doing that: 



Here's one way: 

315 IF FIRE0=1 THEN 
MX0=X0+3: 
MY0=Y0+7: 
DIR0=MOVE0: 
FIRE0=FIRE0+1 



ANSWER 



Note that with this code, DIRO will be set to the stick deflection value only 
on the first pass through the loop. Also notice that I set MYO to YO+7. That's 
because I wanted to move the missile down a bit from the player image. 
Remember that the player image has zeros at the top so she erases herself as 
she moves down the screen.* I set MXO to XO+3 because a value of XO would 
put the missile at the far left edge of the player image — I want tht missile to be 
hidden "underneath" the player. 






Putting the Missile on the Screen 

■ Now we're ready to put the missile on the screen! We simply erase the 
data in MISSILESS, POKE HPOSMO with MXO, and set MISSILESS(MYO) 
equal to our missile image string. Can you write the code? 



ANSWER 



335 MISSILESS=BUFFERS: 
POKE HPOSM0.MX0: 
MISSILESS(MYO)=MIMAGEOS 



Also, we'll need to make these changes: 
Add this to line 10060: 
HPOSM0=53252 



*By now you have probably noticed that I sometimes refer to our player as male and sometimes as 
female. Working with a feminist writer taught me to do this as a way to avoid sexist writing. I hope 
it doesn't jar you too much. Of course, you might still complain that the player doesn't look at all 
female— oh well. 
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Add line 11070: 

11070 DIM MIMAGE0$(1):MIMAGE0$=CHR$(3) 

Change lines 13000 and 13010 to: 

13000X0=120 
13010 YO+43 

Change line 2 to: 

SAVE "D:MISSILE.SAV":STOP 

Change line 14000 to: 

14000 ? "To fire missile, move joystick and push fire 

button. ":RETURN 

Change line 15 so it reads: 

15 POP:PLAYER0$(Y0) = LEGS1$: 
GOTO 300 

Delete lines 1000 through 1020. 

Now (finally) we're about ready to take a preliminary test run of our 
missile routine. (Assuming you've typed in all of the preceding lines along the 
way) But first, in line 315 change MXO=X0+3 to: 

MX0=X0-10 

Why? Because I want you to be able to see the missile so you can verify that 
your routine is working at this point. Otherwise, the missile will be positioned 
directionally on top of the player and you won't be able to see it. (Remember, 
the missile is normally the same color as the player it belongs to.) 

Also, put a stop at line 340 just to temporarily freeze the action so you can 
see exactly where the missile appears when you press the fire button. 

I've covered a lot, I know. So for your convenience, here is a listing of the 
new program with the changes circled, 



c 



1 GQSUB 2000: GOTO 200 

2 SAVE "D: MISSILE. SAV'fsTOP : REM DISK) 

30 _ — ~ 



4 REM ADJUST HORIZONTAL * VERTICAL 
COORDINATES 

5 XO=XO+SP: YO=YO+SP: RETURN 
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6 yo=yg-sp: xo=xo+sp: return 

7 xo=xo+sp: return 

9 xq=xo-sp: yo=yo+sp: return 
io xo«xo-SP: yo=yo-sp: return 
ii xo=xo-sp: return 

13 yo=yo+sp: return 

14 yo=yo-sp: return 

115 pop : flayerq* <y0)=legs1$: g oto 300 ) 

29 rem move player' s legs ' 

f 30 Z = Z+l:POKE HPOSPO,XO:IF Z<4 THEN PL") 
\ AYEROJ ( YO ) =LEG5 1 * : RETURN * 

31 IF Z<7 THEN PLAYERO* ( YO) =LEGS2* : RET 
URN 

32 PLAYERO* <Y0)=LEGS3*: IF Z=9 THEN Z=0 
: RETURN 

33 RETURN 

199 REM MAIN LOOP 

200 GOSUB PEEK (JOYSTICK) : GOSUB MOVELEG 



S 

260 REM 
270 REM 
280 REM 
290 REM 



ddkt^ "GoTo Vloo" 



300 REM ^ 

301 IF PEEK(BUTTONO)=0 AND PEEK(JOYSTI 
CKX>1S THEN MOVEO=PEEK (JOYSTICK) : FIRE 
0«FIREO+1 

305 IF FIREO=0 THEN GOTO 200 
315 IF FIRE0=1 THEN MX0=X0-10: MY0=Y0+7 
: D I RO=MOVEO : F I REO=F I REO+ 1 
335 MISSILES*=BUFFER*:POKE hposmo, mxq: 
M I SS I LES* ( MYO ) =M I MAGEO* 
>40 STOP , 



600 GRAPHICS 0:TRAP 610: FOR 1=1 TO 128 
:? 15" "; ASC(PLAYER0*(I) ) :NEXT I: STOP 

6 1 o enq^^- ck&dls I ooo thnougL I OSLO 

1999 REM SETUP ROUTINES FOLLOW. 

2000 GOSUB 10000: REM MISC. INITIALI- 
ZATION 

2005 GRAPHICS 5: REM SET GR. MODE 

BEFORE PMG SETUP." 

2010 GOSUB 11000: REM PMG SETUP 
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2015 GDSUB 12000: REM DRAM PL AV FIELD 
2020 GDSUB 13000: REM PLAYER COLOR ANT) 
SCREEN POSITION 

2025 GGSUB 14000: REM DISPLAY MESSAGE 
2130 RETURN 

2999 rem error correction routine 

3000 playero*=buffer*: y0=128: x0=80: z=0 
:trap 3000: goto 200 

10000 rem misc. initialization 

10050 J0YSTICK=632." HP0SP0-53248:PRI0R= 

623: M0VELEGS=30: SF-1 : PR=8: BUTT0N0=644: 
SETSOUND- 1000: 80=53760 

1 0060 BUTT0N0=644 : SETSOUN p=1000: S0=537 
60 r. DV0=53761 : HPQSM0=53252 ^HPQSM0=53252 ) 
: RETURN — ~ ~— " — ™ 

10999 REM PMG SETUP ROUTINE 

11000 DIM FILLER1*<1) , FILLER2*( (INT (AD 
R(FILLER1*) /1024)+1>*1024-ADR(FILLER1* 
)-l) 

11010 DIM BUFFER* (384) , MISSILES* (128) , 

PLAYERO* (128) , PLAYER1* (128) , PLAYER2* ( 1 

28) ,PLAYER3*(128) 

1 1 020 BUFFER*=CHR* ( ) 

1 1 030 BUFFER* ( 384 ) =CHR* ( ) 

11040 BUFFER* (2) =BUFFER* 

1 1045 MISSILES*=BUFFER«: PLAYERO*=BUFFE 

R*: PLAYER1*=BUFFER*: PLAYER2*=BUFFER*: P 

LAYER3*=BUFFER* 

11050 DIM LEGS1*(17) ,LEGS2*(17) , LEGS3* 

(17) 

11060 FOR 1=1 TO 17: READ A: LEGS1* ( I , I ) 

=CHR*(A) :NEXT I 

11065 FOR 1=1 TO 17: READ A: LEGS2* < I , I ) 

=CHR*(A) :NEXT I 

11067 FOR 1=1 TO 17: READ A: LEGS3* ( I , I ) 

=CHR*(A) :NEXT I __^^ 

^Tl070 DI M MIMAGE0*(1) :MIMAGE0*=CHR*(3p) 

11080 POKE 54279, ADR (BUFFER*) /256: REM 

DTELL ANTIC WHERE START OF PM MEMORY I 

S 

11085 POKE 559, 46: REM DOUBLE LINE RES. 
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11090 POKE 53277, 3: REM TURN ON PMG 
11110 POKE PRIOR, PR 

11299 RETURN 

11300 DATA 0,0,0,28,20,8,28,58,89,24,6 
0, 36, 36, 102, 0, 0, 

11310 DATA 0,0,0,28,28,8,28,58,89,24,4 
0, 76, 68, 68, 0, 0, 

11320 DATA 0,0,0,28,28,8,28,58,89,24,5 
6, 72, 132, 130, 0, 0, O 

11999 REM BRAN PLAYFIELD 

12000 SETCOLOR 4, 16, 2: COLOR 1 
12010 PLOT 0,20:DRAWT0 40,20 

12020 COLOR 3:DRAWT0 60, 35: COLOR 2:DRA 

WTO 79,35 

12030 RETURN 

12999 REM SET PLAYER COLOR AND 

POSITION 



f 13000 X0=120^ 
V 13010 Y0=43 J 



13020 POKE 704, 8B 

13030 POKE 53248, XO: REM POKE HORI- 
ZONTAL VALUE INTO HORIZONTONAL POSIT 10 
N REBISTER. 

13040 PLAYER0*(Y0)=LEGS1*:REM PUT 
IMAGE INTO PROPER BYTE OF PLAYERO. YO 
DETERMINES VERTICAL POSITION 
13050 RETURN 



a 



14000 ? "To fire missile, move joys 
k and push fire but ton ": RETURN 




When your new program is working properly, the missile will appear to 
the left of the player. That's because we set the horizontal coordinate (MXO) to 
ten less than the player coordinate. Now that we've got the missile on the 
screen, let's see about moving it. But first, go back and change line 315 so it says 
MX0=X0+3. 

Moving the Missile 

Now let's get on with animating that missile. For now, delete the TRAP state- 
ment from line 1. Now, remember lines 5 through 15? Let's review. We used 
them to adjust the coordinates for the player's position. If the stick reading is 7 
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(right), then we GOSUB 7. Line 7 is a "minisubroutine" that increments XO and 
immediately returns. We can use that same approach to move our missiles. To 
do that; we will write a similar routine that starts at an offset of 60 from the first 
one. That is, instead of beginning at line 5, our new missile subroutine will start 
at line 65 (5+60). Instead of adjusting XO and Y0, we will adjust MXO and MYO, 
the missile coordinates. Here is the complete missile coordinate adjustment 
routine: 



65 MXO=MXO+MSO 

66 MY0=MY0-M50 

67 MXO«MXO+MSO 

69 MXO=MXO-MSO 

70 MX0=MX0-MS0 

71 MXO=MXO-MS0 

73 MYO=MYO+MS0 

74 MYO=MYO~MS0 



MYO=MYO+MSO: RETURN 

MXO=MXO+MSO: RETURN 

RETURN 

MYO=MYO+MSO: RETURN 

MYO=MYQ-MSO: RETURN 

RETURN 

RETURN 

RETURN 



Notice that we are now using MS0 to increment or decrement our missile 
coordinates. (MS0=Speed of Missile 0.) 

In addition to the above lines, we will need these lines in our missile 
move routine: 

320 IF FIRE0>1 THEN GOSUB DIRO+60 
449 GOTO 200 

■ According to line 320, where will control pass if the joystick is pushed 
forward? (Hint: the number 14 is returned when you push the stick 
forward.) 



ANSWER 



Control will pass to line 74 (14+60). 



What happens at line 74? 







ANSWER 








We decrement MYO, 


and the effect is that our missile will move 


up 


the 


screen. (The smaller MYO, 


the higher will be the position 


of the missile 


on 


the screen.) 
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Let's try it. In summary: 

1. Add lines 65 through 75 above. 

2. Add line 320. 

3. In line 10060 initialize MSO to 6 (MS0=6). 

4. Delete line 340. 

5. Add line 499. 

6. Delete the TRAP statement from line 1. 

Then, save and then run the program. If all went well, your player can 
now fire the missile in any one of six directons! 



ERROR ROUTINE 

Having played around a bit firing missiles, you are probably tired of seeing that 
error message pop up. You know, the one that comes up every time you fire a 
missile off the screen. That's fairly easy to fix. Let's write an error correction 
routine for it. 

Once again, let's begin our program with a TRAP statement at line 1: 

1 TRAP 3000:GOSUB 2000:GOTO 200 

Whenever an error occurs, program control will branch to line 3000. I've 
used a high line number so that the trap routine is out of the way of our main 
loop. Now when an error occurs, control will pass to an error correction routine 
at line 3000. The error correction routine will check for various error conditions 
and then correct them. I know, we did this in a previous chapter, but this time 
the correction routine will be a bit more detailed. 

First, let's handle the situation where the player moves off the screen too 
far to the right. Horizontal coordinate 21 is just off the screen to the right. So if 
the X0 coordinate is greater than 210 let's reset X0 to 210. The statement IF 
X0>210 THEN X0=210 will do that nicely. 

In the same way we can reset the other X0 and Y0 values if they move 
too far off the screen. Like this: 

3000 IF X0>210 THEN X0=210 
3010 IF X0<39 THEN X0=39 
3020 IF Y0<1 THEN Y0=1 
3030 IF Y0>128 THEN Y0=128 
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In addition, we need to reset the leg movement counter Z. We can do 
that with the statement Z=0. Let's add it at line 3035: 

3035 Z=0 

That takes care of our player. Now she can hide off the screen — even move 
around off-screen and then come back. 

Let's fix the missile, too. Here's a simple way to do it for now: reset the XO 
and Y0 coordinates whenever an error occurs. Reset them to what? Well, let's 
simply reset them to the player's coordinates, like this: 

3040 MX0=X0:MY0=Y0 

Also, we need to turn off the missile sound when an error occurs. We can 
do that simply by setting Dl to zero: 

3050 D1=0 

Next, we need to turn off the missile routine, so it doesn't continue to 
adjust the MX0 and MY0 coordinates. We do that by setting FIRE0 to zero: 

3060 FIRE0=0 

Finally, we need to include another TRAP statement so that if another 
error occurs control will once again return to line 3000. Then we canjump back 
to line 300 in the main routine: 

3080 TRAP3000:GOTO 200 

Add these lines. Then you'll be able to fire missiles from an ambush 
position — while the player is hiding off the screen! 






Our missile move routine is now pretty much finished. But let's add a few 



embellishments. First, let's add sound to the firing of the missile 
Add line 300 as follows: 

300 POKE SD1.P1: 
POKEDV1.D1 

At line 10070 initialize PI, Dl, SD1, and DV1 as follows: 

P1=10 (Pitch for sound) 

D1=0 (Distortion/Volume) 

SD1=53762 (Pitch Register) 

DV1 =53763 (Distortion/Volume Register) 
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Also, remove the RETURN from line 10060 and put RETURN at line 10900. 

Now we can use variable Dl to set the volume of our missile sound. A 
good place to do this is on the first pass through the missile loop. If we set the 
volume to maximum on the first pass and then decrement it on each successive 
pass, we can create an explosive type sound that gradually fades away. We 
can set the volume to maximum by writing Dl=15. 

■ Where would be a good place to insert that statement? 









ANSWER 










At line 


315 where we test to see if we are 


on 


the first 


pass through 


the 


missile routine. 


So add D1- 


=15 to the end of 1 


ne 


315. 







Now we still need to decrement Dl. Let's do that at line 330. We can 
decrement Dl easily enough with D1=D1-1. But that's not enough, because that 
way Dl will eventually become a minus value and we will get an errror 
message. 

■ How can we avoid that? Write the code. 



ANSWER 

Here's how I did it: 

330 D1=D1-1:IF DK1 THEN D1=0 



Add line 330. Save the program and run it. You will now hear an explosive 
sound whenever you fire a missile. 



MISSILE SIZE REGISTER 






Now let's play with the missile size register. That's a register that lets us instantly 
increase or decrease the width of a missile. We can set a missile's size to nor- 
mal, double, or quadruple width. The missile size register, at location 53260, 
controls the size of all missiles. 
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Here's a chart showing the proper numbers to poke in for various missile 



Missile 




Number 


Norr 








1 





2 





3 






sizes. 



Double Quadruple 

1 3 

4 12 

16 48 

64 192 

Important: if you want to set the size of two or more missiles at once, 
then add the proper values for each missile depending on the desired size. 
Then poke the total into location 53260. 

For example, to set missile 3 to quadruple size and missile 1 to double 
size, you would poke 196 into 53260. (192 gives quad size for missile 3, and 4 
gives double size for missile 1. We get 196 by adding 192 and 4.) 

■ Suppose you wanted to set missile to quad size and missile 1 to double 
size? What number would you poke into 53260? 



ANSWER 

7 (3+4=7) 



How would you set missiles and 1 to double size? 



ANSWER 
POKE 53260,5 



To make our program easier to read, let's set up a variable called SIZEM 
(size of missiles) at line 10070, like so: SIZEM=53260. 

We can create a nice effect by poking a random number into SIZEM. First 
(also at line 10070) let's set up a variable called RANDOM: RANDOM=53770. 
Location 53770 is constantly being updated by Atari's operating system with a 
random number. So a quick way to get a random number is to "peek" into 
location 53770. 
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Write a statement to poke a random number into the size register for 
missiles. 



ANSWER 



Here's one easy way: 

POKE SIZEM.PEEK(RANDOM) 



Try it. Be sure to initialize SIZEM and RANDOM at line 10070. Then add 
POKE SIZEM,PEEK(RANDOM) to line 300. 

You'll now see the missile randomly expand to various widths as it sails 
across the screen. Notice the different effect produced by firing the missile 
vertically versus firing it horizontally. 



COMPLETE LISTING 

Here is a complete listing of the missile program that we have developed in 
this chapter. Again, I have circled the lines that are to be changed or added. Be 
sure to save it to disk or tape. You'll need it. Remember, each chapter will build 
on the previous program in some way. 

In the next chapter, you learn how to create single-line resolution PMG! 

1 TRAP 3000:G0SUB 2000: GOTO 200 

2 SAVE "D: MISSILE. SAV": STOP : REM DISK 
30 

4 REM ADJUST HORIZONTAL & VERTICAL 
COORDINATES 

5 xo=xo+sp: yo=yo+sp: return 

6 yo=yo-sp: xo=xo+sp: return 

7 XO=XO+SP: RETURN 

9 XO=XO-SP: YO=YO+SP: RETURN 

10 XO=XO-SP: YO=YO-SP: RETURN 

11 XO=XO-SP: RETURN 

1 3 YO=YO+SP : RETURN 

14 YO=YO-SP: RETURN 

15 POP :PLAYERO*(YO)=LEGSl*:GOTO 300 

29 REM MOVE PLAYER'S LEGS 

30 Z = Z+l:POKE HPOSPO,XO: IF Z<4 THEN PL. 
A YERO* ( YO ) =LEGS 1 * : RETURN 



106 / Missiles 



31 IF Z<7 THEN PLAYERO* ( YO) =LEGS2»: RET 
URN 

32 PLAYERO* ( YO) =LEGS3«: IF Z=9 THEN Z=0 
: RETURN 

33 RETURN ^ 

MXO=MXO+MSO: MYO=MYO+MSO: RETURN 
MYO=MYO-MSO: MXO=MXO+MSO: RETURN 
MXO=MXO+MSO: RETURN 
MXO=MXO-MSO: MYO=MYO+MSO: RETURN 
MXO=MXO-MSO: MYO=MYO-MSO: RETURN 
MXO=MXO-MSO: RETURN 
MYO=MYO+MSO: RETURN 
MYO=MYO-MSO: RETURN 




199 REM MAIN LOOP 

200 BDSUB PEEK (JOYSTICK) : GOSUB MOVELEG 
S 

260 REM 
270 REM 
280 REM 
»90 REM 



P300 POKE SDl,Pl:PDKE DV 1 , D 1 : POKESIZEM\ 

( , PEEK (RANDOM) 1 

301 IF PEEK(BUTTONO)=0 AND PEEK(JOYSTI 

CK)<>15 THEN MOVEO=PEEK (JOYSTICK) : FIRE 

0=FIRE0+1 

305 IF FIREO=0 THEN GOTO 200 

315 IF FIRE0=1 THEN MX0=X0+3: MY0=Y0+7: 

D I RO=MQVEO : F I REO=F I REO+ 1 : D 1 ■ 1 5 

( 320 IF FIRE0>1 THEN GOSUB DIRO+60 *""\ 

I 330 Dl=Dl-l:IF DKl THEN D1=0 J 

335 MISSILES$=BUFFER*:POKE HPOSMO.MXO: 

f499 GOTO 20CO "XJU{A&, -O^TO 

600 GRAPHICS 0: TRAP 610: FOR 1=1 TO 12S 
:? I;" "; ASC(PLAYER0*(I) > ."NEXT I : STOP 
610 END 

1999 REM SETUP ROUTINES FOLLOMl 

2000 GOSUB 10000: REM MISC. INITIALI- 
ZATION 

2005 GRAPHICS 5: REM SET BR. MODE 
BEFORE PMG SETUP/ 
2010 GOSUB 11000: REM PMG SETUP 
2015 GOSUB 12000: REM BRAN PL AY FIELD 
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REM PLAYER COLOR AND 



REM DISPLAY MESSAGE 



2020 GOSUB 13000: 
SCREEN POSITION 
2025 GOSUB 14000: 
2130 RETURN 

2999 REM ERROR CORRECTION ROU TINE 

3000 IF X0>210 THEN X0=210 ~*\ 
IF X0<39 THEN X0=39 
IF Y0< 1 THEN Y0=1 
IF Y0M28 THEN Y0=128 
Z=0 

MX0=X0:MY0=Y0 
D1=0 
FIREO=0 




TRAR 3000: GOTO 



1 



10000 REM MISC. INITIALIZATION 

1 0050 J OYST I CK=632 : HFQSP0=53248 : PR 1 0R= 

623: M0VELEGS=30: SP=1 : PR=8: BUTT0N0=644: 

SETSOUND* 1000: 80*53760 

10060 BUTT0N0=644: SETSQUND=1000: S0=537 

60:DV0=5376l: HP0SM0=53252: HP0SM0=53252 

<rtUJkXt, fiETURA/ . 

0070 P 1 ■ 1 o : D 1 =0 : SD 1 =53762 : DV 1 =5376: 
IZEM=53260:RANDQM=53770 
10900 RETURN 

10999 REM PNG SETUP ROUTINE 

11000 DIM FILLER1*(1) ,FILLER2*( (INT (AD 
R(FILLER1*) /1024)+1)#1024-ADR(FILLER1* 
)-l) 

11010 DIM BUFFER* (384) , MISSILES* (128) , 

PLAYERO* ( 1 28 ) , PLAYER 1 * ( 1 28 ) , PLA YER2* ( 1 

28) ,PLAYER3*(128) 

11020 BUFFER*=CHR*(0) 

1 1 030 BUFFER* ( 384 ) =CHR* ( ) 

1 1 040 BUFFER* < 2 ) =BUFFER* 

1 1 045 M I SS I LES*=BUFFER* : PL AYERO*=BUFFE 

R* : PLAYER 1 *=BUFFER* : PLAYER2*=BUFFER* : P 

LAYER3*=BUFFER* 

11050 DIM LEGS1*(17) ,LEGS2*(17) , LEGS3* 

(17) 

11060 FDR 1=1 TO 17: READ A: LEGS1* ( I , I ) 

=CHR* (A) :NEXT I 

11065 FOR 1=1 TO 

=CHR*(A) :NEXT I 



17: READ A:LEGS2*(I, I) 
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11067 FOR 1=1 TO 17: READ A: LEGS3* ( I , I ) 

=CHR*(A> :NEXT I 

11070 DIM MIMAGEOSd ) :MIMAGE0*=CHR*(3) 

11 080 POKE 54279, ADR (BUFFER*) / 256: REM 

DTELL ANTIC WHERE START OF PM MEMORY I 

S 

11085 POKE 559, 46: REM DOUBLE LINE RES. 






11090 POKE 53277, 3: REM TURN ON PMG 
11110 POKE PRIOR, PR 

11299 RETURN 

11300 DATA 0,0,0,28,28,8,28,58,89,24,6 
0,36, 36, 102, 0, 0,0 

11310 DATA 0,0,0,28,28,8,28,58,89,24,4 
0,76,68,68,0,0,0 

11320 DATA 0,0,0,28,28,8,28,58,89,24,5 
6,72, 132, 130,0,0,0 

11999 REM DRAN PLAYFIELD 

12000 SETCOLOR 4, 16, 2: COLOR 1 
12010 PLOT O,20:DRAWT0 40,20 

12020 COLOR 3:DRAWT0 60, 35: COLOR 2:DRA 
WTO 79,35 
12030 RETURN 

12999 REM SET PLAYER COLOR AND 
POSITION 

13000 X0=120 
13010 Y0=43 
13020 POKE 704,88 

13030 POKE 53248, XO: REM POKE HORI- 
ZONTAL VALUE INTO HORIZONTONAL 
POSITION REGISTER. 

13040 PLAYER0*(Y0)=LEGS1$:REM PUT _ 

IMAGE INTO PROPER BYTE OF PLAYERO. YO 
DETERMINES VERTICAL POSITION 
13050 RETURN 

14000 ? "To fire missile.- move Joystic 
k and push fire button .": RETURN 




Single-line Resolution 



So far we have been dealing strictly with double-line resolution. Since double- 
line resolution is easier to handle and takes less memory, I'll continue to use it 
for most of the examples in this book. But our little player is so cute in single- 
line resolution! I just couldn't resist introducing him to you. 

Be sure to save copies of the previous double-line resolution programs, 
since future programs will be based on them — not on the program in this chap- 
ter. In fact, I suggest you just read over this chapter without typing in any of the 
examples. Then afteryou've mastered double-line resolution, come back and try 
out the program in this chapter. (Whatever. You'll do it your way, anyway.) 

At the end of this chapter is a complete listing of a program that does 
essentially the same thing as the program in the previous chapter — the only 
difference is that it is in single-line resolution. The program is called SLRES.SAV— 
short for "single-line resolution." Here is a summary of the changes you'll need 
to make to MISSILE.SAV to produce SLRES.SAV: 



LINE 11000 

This is the "filler" line that makes sure that PM memory starts on a 2K boundary. 
The only change is that while the number 1024 appeared in the previous 
program, 2048 appears in this program (1 024=1 K: 2048=2K). 

109 
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LINE 11010 

In the previous program I had a string called BUFFERS dimensioned to 384 
bytes. Well, in single-line resolution, this string needs to be twice as many 
bytes: 384*2 or 768. 

Instead of dimensioning BUFFERS to 768 bytes, I broke it down into three 
strings of 256 bytes each: ERASES, FILLER3S, and FILLER4S. (Notice that it works 
out to be the same thing since 3*256=768.) Also, notice that each of the other 
strings are now 256 bytes long instead of 128— the way they were in double- 
line resolution. And notice that I omitted the dimensioning of PLAYER1S, 
PLAYER2S, and PLAYER3S. 



LINES 11020 THROUGH 11040 

Here I am setting ERASES to binary zeros. Notice the RETURN at the end of line 
1040. 1 broke the PMG setup routine into two parts. (For some unknown reason 
BASIC likes it better this way.) 

Lines 11045 through 11095 make up the next part of the PMG setup. I 
made these lines into another subroutine, which is called immediately after the 
subroutine starting at line 11000. (See the "executive" subroutine beginning at 
line 2000, which calls the various setup routines.) 



LINES 11045 AND 11047 

Here I am initializing MISSILESS and PLAYER0S in a slightly different way. This is 
necessary because of an apparent bug in Atari BASIC. It seems that a statement 
such as MISSILESS=ERASES won't work if MISSILESS is 256 bytes or more. 

In the previous program, line 335 contained the statement MISSILESS 
=BUFFERS, which served to "erase" data from the missile memory area. (Actual- 
ly it fills MISSILESS with zeros.) I had to take this statement out when converting 
the program to single-line resolution. That's because of the apparent bug in 
Atari BASIC that I just mentioned. 

So to accomplish vertical missile movement, I had to find another way to 
erase the missile. I did that by rewriting lines 11070 and 11330. 

LINES 11070 AND 11330 

At line 11070 I dimensioned the missile image string to 13, instead of 1. Why? 
Because I wanted to have the missile erase itself with trailing zeros during 
vertical movement. 



" 



Line 315 / 111 

Notice the zeros in the missile image data at line 11330. These zeros erase 
the missile as it moves vertically. Using this arrangement, I found that I didn't 
need the statement "MISSILESS=ERASE$" at line 335. 



LINE 11085 

This is important. Here I specify single resolution by adding 16 to the 46 that is 
to be poked into location 559, the direct memory access control register. I'll 
explain this more later. (See the "Odds and Ends" chapter if you can't wait.) 



LINES 5 THROUGH 14 

Here I use SY to adjust Y0, where previously I used SP. SY refers to "speed of Y 
(up/down) movement." In single-line resolution, remember, there are twice as 
many vertical locations. So to get approximately the same vertical speed, we 
have to move the player 2 bytes instead ofjust I. Consequently, SY is initialized 
to 2 in line 10070 and SP is still initialized to 1. Horizontal movement is no 
different in single- versus double-line resolution. 

A similar change could also be made for the missile coordinate adjust- 
ment routine at lines 60 through 75. When you get this program running, 
notice how the missiles don't go exactly as you might expect when you fire 
them in a diagonal direction. That's because in single-line resolution there are 
about 224 vertical positions, but only 150 horizontal ones. 






LINE 10070 

In line 10070 I initialized SY to 2 as I just mentioned. 
LINE 315 

To line 315 I added: 
MY0S=MY0 

MY0S is short for MY0SAVE. Here I am saving the vertical coordinate for the 
missile. Notice that I am doing this when the missile's vertical coordinate is first 
set. I use this saved value later in the error correction routine (which begins at 
line 3000) to help me erase the missile from the screen. 
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LINES 3000 THROUGH 3080 

The error correction routine at lines 3000 through 3080 needed quite an over- 
haul because of the differences in vertical coordinates in single-line resolution. 
Also the manner in which I erase a missile is different. I now need to reference 
specific bytes in MISSILESS when erasing the missile. I can no longer merely 
code MISSILESS=BUFFERS to set the missile memory area to zeros. Again, this is 
necessary because of an apparent bug in Atari BASIC. 

That does it. The complete listing for firing missiles in single-line resolu- 
tion follows. To make the required changes easy to see. I have circled them. 
Notice that in line 2, I made a comment to myself that I saved the program on 
disk 30. I suggest you revise this REM statement so it reminds you where you 
saved the program. In the next chapter, we'll put our player in a maze and add 
collision detection! 

1 TRAP 3000:G0SUB 2000: GOTO 200 

( JZ SAVE "D:SLRES.5AV":STQF IJ REM DISK 30 ) 

4 REM fiBJUSJ HORIZONTAL & VERTICAL 
COORDINATES 

5 xo=xo+sp:yo=yo+sy: RETURN 

6 yo=yo-sy: xo=xo+sp: return - 

7 xo=xo+sp: return 

9 xo=xo-sp: yo=yo+sy: return 
io xo=xo-sp: yo=yo-sy: return 
ii xo=xo-sp: return 

13 yo=yo+sy: return 

14 y0=y0-sy: return 

15 pop :playero*(yo)=lebsl*:goto 300 

29 rem move player's less 

30 z=z+l:poke hpospo, x0: if z<4 then pl 
ayero* ( yo ) =legg 1 $ : return 

31 if z<7 then playero* ( yo) =legs2*: ret 

URN 

32 PLAYERO* (Y0)=LEGS3$: IF Z=9 THEN Z=0 
: RETURN 

33 RETURN 

65 mxo=mxo+mso: my0=my0+ms0: return 

66 myo=myo-mso:mxo=mxo+mso: return — 

67 mxo=mxo+mso: return 

69 mxo=mxo-mso:myo=myo+mso: return 

70 mxo=mxo-mso:myo=myo-mso: return 

71 mxo=mxo-ms0: return 






73 MYO=MYO+MSO: RETURN 

74 MYO=MYO-MSO: RETURN 
199 REM MAIN LOOP 



200 


GOSUB 


PEEK ( 


260 


REM 




270 


REM 




280 


REM 




290 


REM 




300 


POKE 


BD 1 , P 1 


, PEEK (RANDOM) 



Lines 3000 through 3080 / 113 



BOSUB MOVELEB 



POKE DVl,Dl:POKE SIZEM 



301 IF PEEK(BUTTONO)=0 AND PEEK(JOYSTI 

CK)<>15 THEN MOVEO=PEEK (JOYSTICK) : FIRE 

0=FIRE0+1 

305 IF FIREO=0 THEN GOTO 200 

315 IF FIRE0=1 THEN MX0=X0+3: M Y0=Y0+7: 

D I RO=MOVEO : F I REO=F I REO+ 1 : D 1 = 1 5 Jm YOS=M Y 

3) A 

320 IF FIREOM THEN GOSUB DIRO+60 

330 Dl=Dl-l:IF DK1 THEN D1=0 

335 POKE HP0SM0,MX0: MISSILES* ( MYO ) =M I M 

AGEO* 



c 



499 GOTO 200 

600 GRAPHICS 0:TRAP 610: FOR 1=1 TO 128 

:? IS" "5 ASC(PLAYERO*(I) ) :NEXT I : STOP 

610 END 

1999 REM SETUP ROUTINES FOLLOW. 

2000 GOSUB 10000: REM MISC. INITIALI- 
ZATION 

2005 GRAPHICS 5: REM SET BR. MODE 

BEFORE PMG SETUP/ 

2010 GOSUB 1 1 000 : GOSUB 11045: REM PMG 

S£ TUP 

2015 GOSUB 12000: REM DRAM PL A YF I ELD 

2020 GOSUB 13000: REM PLAYER COLOR AND 

SCREEN POSITION 

2025 GOSUB 14000: REM DISPLAY MESSAGE 

2130 RETURN 

2999 REM ERROR CORRECTION ROUTINE 

3000 IF X0>210 THEN X0=210:REM CORRECT 
PLAYER COORDINATES 

3010 IF XCK39 THEN X0=39 
3020 IF YCK1 THEN Y0=1 
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Q 



5030 IF YO: 



THEN 



5035 Z=0 



G 



.^040 IF MYOX1 OR MY0>240 THEN MY0=1 
5042 IF MX0<40 OR MXO210 THEN MX0=4< 

5045 MISSILES* (MYOS)=ERASE* 

3050 D1=0:REM TURN OFF MISSILE SOUND 

3060 FIREO=0:REM TURN OFF FIRE FLAB 

3080 TRAP 3000: GOTO 300 

10000 REM MISC. INITIALIZATION 

1 0050 J OYST I CK=632 : HP0SP0=5324B : PR 1 0R= 

623: M0VELEGS=30". SP=1 : PR=8: BUTT0N0=644: 

SETS0UND=1000: S0=53760 

10060 BUTTONO=644: SETSOUND= 1000: 30=537 

60 : DV0=5376 1 : HP0SM0=53252 : HP0SM0=53252 

: MS0=6 

1 0070 P 1 = 1 : D 1 =0 : SD 1 =53 762: DV 1 =53763 : S 

I ZEM=53260 ." RAND0M=53770 :\SY=2 J 

10900 RETURN 

10999 REM PM8 SETUP ROUTINE 

11000 DIM FILLER1*<1) , FILLER2*( (INT (AD 
R (FILLER1*) /2048) +1 ) *204B-ADR (FILLER1* 
)-l) 

11010 DIM ERASE* (256) , FILLERS* (256) ,FI 
LLER4*(256) , MISSILES* (256) , PLAYERO* (25 
6) 

ERASE*=CHR*(0) 
ERASE* ( 256 ) =CHR* ( ) 
ERASE* ( 2 ) =ERASE* ^ETURN ) 
MISSILES*=CHR*(0): MISSILES* (256) 
CHR*(0) : MISSILES* (2) =MISSILES* 




1 1 047 PLAYER0*=CHR* ( ) : PLAYERO* ( 256 ) =C 

HR* ( O ) : PLAYERO* ( 2 ) =PLAYERO* 

11050 DIM LEGS1*<17> , LEGS2* (17) , LEGS3* 

(17) 

11060 FOR 1=1 TO 

=CHR*(A) :NEXT I 

11065 FOR 1=1 TO 

=CHR*(A) :NEXT I 

11067 FOR 1=1 TO 

=CHR*(A) ."NEXT I 



17:READ A:LEGS1*(I 



17: READ A:LEGS2*(I 



17: READ A:LEGS3*(I 



I) 
I) 
I) 
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11070 DIM M IMAGED* ( 13) : FOR 1=1 TO 13: R 
EAD A: MIMAGEO* (1,1) =CHR* (A) : NEXT I 



HOBO POKE 54279, ADR (ERASE*) /256: REM D 
TELL ANTIC WHERE START OF PM MEMORY IS 



Cl"l085 POKE ! 
RESOLUTION 



D 



1 090 POKE 53 277 . 3 : REM TURN ON PMG 
Hi 095 RETURN ^ 
11110 PflkE PRI OR , PR 

11299 RETURN 

11300 DATA 0,0,0,28,28,8,28,58,89,24,6 
0, 36, 36, 102, 0, 0, 

11310 DATA 0,0,0,28,29,8,28,58,89,24,4 

0, 76, 68, 68,0, 0, 

11320 DATA 0,0,0,28,28,8,28,58,89,24,5 

6,72, 132, 130,0,0,0 

til 330 DATA , , , , , , 3 , oTo , , , , 0*) 

11999 REM BRAN PLAYFIELD 

12000 SETCOLOR 4,16,2:C0L0R 1 
12010 PLOT 0,20:DRAWT0 40,20 

12020 COLOR 3:DRAWT0 60, 35: COLOR 2:DRA 
WTO 79,35 
12030 RETURN 

12999 REM S£ 7 PLAYER COLOR AND 
POSITION 

13000 X 0=1 20 
13010 Y0=43 
13020 POKE 704,88 

13030 POKE 53248, XO: REM POKE HORI- 
ZONTAL VALUE INTO HORIZONTONAL POSIT 10 
N REGISTER. 

13040 PLAYER0*(Y0)=LEGS1*:REM PUT 
IMAGE INTO PROPER BYTE OF PLAYERO. VO 
DETERMINES VERTICAL POSITION 
13050 RETURN 

14000 ? "To fire missile, move Joystic 
k and push fire but ton .": RETURN 




Detecting Collisions 



Suppose a player fires a missile at an alien attacking space craft. Wouldn't it be 
nice to have a simple way to tell when there is a collision between the missile 
and alien ship? Or suppose you're making a maze game. Would you like to be 
able to detect when a player touches a maze wall? 



COLLISION DETECTION REGISTERS 

You can. Collision detection is easy with PMGI The Atari engineers wisely 
provided several collision detection registers for this purpose. Here they are: 



Missile Collisions 




Memory Location 


Shows: 


53248 


Missile to playfield collision 


53249 


Missile 1 to playfield collision 


53250 


Missile 2 to playfield collision 


53251 


Missile 3 to playfield collision 



117 
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53256 
53257 
53258 
53259 



Missile to player collision 
Missile 1 to player collision 
Missile 2 to player collision 
Missile 3 to player collision 



- 



Player Collisions 



Memory Location 


Shows: 


53260 


Player to player collisions 


53261 


Player 1 to player collisions 


53262 


Player 2 to player collisions 


53263 


Player 3 to player collisions 


53252 


Player to playfield 


53253 


Player 1 to playfield 


53254 


Player 2 to playfield 


53255 


Player 3 to playfield 



ASSIGNING VARIABLE NAMES 

To simplify your programming task, I recommend that you assign a variable 
name to each collision register you need to use. It's a lot easier to keep track of 
variable names than all those memory locations.* 
Atari recommends variable names such as these: 

MOPF (missile to playfield collision) 
M1PF (missile 1 to playfield collision) 

In the demonstration program in this chapter we will be using two 
collision registers: MOPF and POPF. 

■ What register do you think POPF refers to? 



'Later, though, you may wish to go back to using constants (such as 53260, 53261, etc.). That's 
because Atari BASIC only allows you 128 variable names. Also, statements with constants actually 
execute slightly faster than those using a corresponding variable! (This is not true with other 
computers such as the PET and Apple, where variables execute 10 to 40 times faster than con- 
stants.) I'd like to thank B. B. Garrett for clarifying this in his informative article "Atari Times" in the 
May, I983 issue of Compute! 
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ANSWER 

Player to playfield collision (53252) 



If you have the program from the previous chapter loaded into memory, 
you might want to initialize POPF and MOPF right now by adding these state- 
ments to line 10070: 

P0PF=53252: 
M0PF=53248 



READING COLLISION REGISTERS 

You can read a collision register with a peek command. For example: 
COLLISION=PEEK(P0PF) 

After this statement executes, COLLISION will contain either 0,1,2, or 4. 
In our sample program you will find that: 

• If POPF contains a zero, then there was no collision. 

• If POPF contains a 1, then PLAYER collided with that part of the 
playfield drawn with COLOR I, 

• If POPF contains a 2, then PLAYER 1 collided with that part of the 
playfield drawn with COLOR 2. 

• If POPF contains a 4, then PLAYER 1 collided with that part of the 
playfield drawn with COLOR 3. 

Ok, try this one. Suppose you draw a line on the screen with these 
statements: 

GRAPHICS 7: 

SETCOLOR 2,3,4: COLOR 3: 

PLOT 0,0: DRAWTO 159,0 

Furthermore, suppose you read a collision register like this: 
COLLISION=PEEK(P0PF) 

■ What value will be in COLLISION if playerO is touching the line you drew? 
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ANSWER 

4 (a 4 shows a collision with a playfield drawn with COLOR 3). 



MULTIPLE COLLISIONS 

Once a collision occurs, the collision register retains the number that was 
placed in it. If a second collision occurs, the next number is added to the 
number that already exists there. 

■ Suppose player collides with a playfield drawn with COLOR 1 and then 
collides with a playfield drawn with COLOR 3. What value will be the 
collision register? (Careful now, this one is a bit tricky.) 







ANSWER 


5 (the 1 from the 


first coll 


sion will be added to the 4 from the second 


collision). 







CLEARING COLLISION REGISTERS 

Since the collision registers retain the values put in them when a collision 
occurs, it's important to reset them. This is almost as easy as taking candy from 
a baby. All you do is poke a 1 into the HIT CLEAR register at location 53278. 

I suggest you use a variable for the HIT CLEAR register. Let's call it HITCLR. 
At line 10070 insert this statement: 

HITCLR=53278 

Often we think of clearing something by poking zeros in it. But this is 
different; here we are turning on the hit clear switch. That's why we poke it 
with 1 rather than 0. 



When we poke a 1 into HITCLR what do you think happens? 

a. All collision registers are cleared. 

b. Only selected registers are cleared. 



" 
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ANSWER 



You're right if you said "a. All collision registers are cleared." 



USING COLLISION REGISTERS 

Often programmers peek at the collision registers and then use a series of 
IF-statements to decide on what action to take. But there's a much better way. 
Remember, in Atari BASIC you can GOSUB a variable or even GOSUB a 
PEEKED value! We did this in our joystick routine, and we can also do it with 
collision registers. 

■ Suppose we want to execute a subroutine that starts at line 41 if player 
collides with a COLOR 1 playfield.* Write a statement to make that 
happen. (GOSUB the value in POPF plus an offset.) 



ANSWER 



GOSUB PEEK(POPF)+40 



Now suppose player hits a COLOR 3 playfield. At what line number 
must we have a subroutine to handle this possibility? 







ANSWER 










We need a 


subroutine at line 


44. 


That's because POPF 


will 


contain a 


4 


if 


player hits 


a COLOR 3 playfield. 













DRAWING A PLAYFIELD 

Now let's use some of these techniques in a PMG program. First, let's draw a 
playfield. We'll make it a maze so that in a later chapter we can expand the pro- 
gram into a full-fledged game. 



*ln this book, a COLOR I playfield is simply a playfield drawn with COLOR 1. The 
term "playfield I ," as used in the Atari technical manual, is not synonymous with the 
term "COLOR 1 playfield." 
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We've already reserved lines 12000-13000 for drawing a playfield, so let's 
put our new playfield subroutine there. (Note that we need to delete the 
previous playfield, which was contained in lines 12000, 12010, 12020, and 
12030.) 

Here are the lines for the new playfield subroutine. I suggest you enter 
them now. 

11999 REM VRf)H PLAYFIELD 

12000 SETCOLOR 2, 3, 4: COLOR 1 

12010 PLOT 0,0:DRAWTO 159,0: DRAWTO 159 

,79:DRAWT0 0,79: DRAWTO 0,0 

12013 COLOR 2 

12020 PLOT 80, 61: DRAWTO 80 ,79: PLOT 0,6 

0: DRAWTO 30,60:DRAWT0 30,79 

12025 COLOR 3 

12030 PLOT 52, 60: DRAWTO 52, 45: DRAWTO 1 

10, 45: DRAWTO 1 10, 60: DRAWTO 137, 60: DRAW 

TO 137, 45: DRAWTO 110, 45: PLOT 159,32 

12040 DRAWTO 110, 32: PLOT 80, 45: DRAWTO 

80, 20: PLOT 130, 16: DRAWTO 130, 14: DRAWTO 

127, 14:DRAWT0 127, 16: DRAWTO 130,16 
12050 PLOT 43,0: DRAWTO 43, 30: PLOT 52,4 
5: DRAWTO 22, 45: DRAWTO 22, 13: PLOT 103,0 
." DRAWTO 1 03 ,17: POKE 559 , 34 : RETURN 

Also, let's revise lines 2010 and 2015 so that line 2010 becomes 2015 and 
2015 becomes 2010. It seems that PMG works better when the playfield is 
drawn before the PMG setup is executed. 

And at line 2005 change GRAPHICS 5 to GRAPHICS 7 since our new 
playfield requires that graphics mode. 



REVISING THE MAIN LOOP 

Now let's revise the main loop of our program so that it detects when our 
player touches the sides of the walls. First, change line 200 into line 201. Do this 
so that we can create some new collision detection routines at line 200. 

Now at the beginning of line 200, let's simply print the contents of the 
collision register— just so we can see what they contain when various objects 
collide. This is easy to do, like so: 

? "P0PF=";PEEK(P0PF), 
"M0PF=";PEEK(M0PF) 
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Next, also at line 200, let's call for the execution of the two collision detection 
subroutines, one for POPF and one for MOPF. And let's arrange things so that if 
there is no collision, we immediately return from each subroutine. We'll let the 
POPF subroutine start at line 40 and the MOPF subroutine start at line 50. 
Here's the call to the MOPF subroutine: 

GOSUB PEEK(M0PF)+40: 



Now you write the call to the POPF subroutine: 



ANSWER 



GOSUB PEEK(P0PF)+50 



Altogether then, line 200 will look like this: 

200? "P0PF=";PEEK(P0PF), 
"M0PF=";PEEK(M0PF): 
GOSUB PEEK(M0PF)+40: 
GOSUB PEEK(P0PF)+50 



PLAYER-PLAYFIELD COLLISIONS 



Simple right? Now all we need to do is decide what we want to happen when 
a collision occurs. For now, let's fix things so that our player cannot walk 
through the maze walls. Here's how we'll do it. At the beginning of line 201 
we'll save the X0 and Y0 coordinates by inserting the statement X0A=X0 and 
Y0A-Y0: 

201 Y0A=Y0:X0A=X0: 

GOSUB PEEK(JOYSTICK): 
GOSUB MOVELEGS 

Then when our player hits a maze wall, we'll reset X0 and Y0 back to what they 
were before the collision. Got it? 

Suppose our player hits a COLOR I playfield. Then POPF will contain a "I," 
and control will pass to line 41 (as a result of GOSUB PEEK(P0PF)+40). Then at 
line 41 all we need to do is: 
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1. Set the YO and XO coordinates to what they were before the collision. 

2. Clear the collision registers by poking a 1 into HITCLR. 

■ See if you can write the code for line 41: 



ANSWER 



41 X0=X0A:Y0=Y0A:POKE HITCLRJ .'RETURN 



We also need this same subroutine at line 42. That's because POPF will 
contain a 2 if our player hits a COLOR 2 playfield. 

If our player hits a COLOR 3 playfield, POPF will contain a 4 (strange as 
this may seem). 

■ So what line will be executed if our player hits a COLOR 3 playfield? 



ANSWER 



44 (Since 40+4=44.] 



So what code do we need at line 44? 



ANSWER 



44 X0=X0A:Y0=Y0A:POKE HITCLR.l. RETURN 



Let's look at the playfield detection statement more closely. It is: GOSUB 
PEEK(M0PF+40). 

■ If the player does not hit anything, POPF will contain a zero. So where will 
control pass when the playfield detection statement is executed? 



ANSWER 



Control will pass to line 40 (0+40=40). 
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What code would be appropriate for line 40? (Hint: we don't really need 
to do anything since no collision has occurred. All we need to do is get 
back to the main loop.) 



ANSWER 

All we need is a RETURN statement at line 40. This will return control to the 
main loop. 



MISSILE COLLISIONS 

The missile collision subroutines start at line 50 since the calling routine is 
GOSUB M0PF+50. If no missile-playfield collision has occurred, we won't need 
any specific action. 

■ What will the code be for line 50? 



ANSWER 



50 RETURN 



If a missile hits a wall, we will want to do these things: 

• Move the missile off the screen by poking zero into HPOSM0. 

• Turn off the missile sound. 

• Turn off the missile move indicator (FIRE0). 

• Clear the collision registers. 

Since we will have to do this whenever a missile hits a wall, let's put it into 
a subroutine at line 190. See if you can write the code: 



ANSWER 



190 POKE HPOSM0.0: 
D1=0: 
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FIRE0=0: 

POKEHITCLR.l: 

RETURN 



Now if a missile hits playfield 1, to which line will control pass'- 



ANSWER 



51 (MOPFwill contain I. 1+50=51) 



What additional line numbers will we need for playfields 2 and 3? 





ANSWER 






We'll need 1 


ne 52 and line 54. (Remember, 


if a missile hits 


playfield 3 then 


the collision 


register will contain a 4.) 







Line 190 contains the commands that we want executed if a missile hits a 
wall so at line 52 all we need is: 

52 GOSUB 190:RETURN 

Similarly, at lines 53 and 54 we'll use the same code: 

53 GOSUB 190:RETURN 

54 GOSUB 190:RETURN 



TRY IT 

Make all the changes I've discussed so far to MISSILE. SAV. Also, change line 2 

to: 

SAVE "D:MISSCOL.SAV":STOP 

All the changes are summarized in the listing that follows: 

1 TRAP 3000: GOSUB 2000: GOTO 200 

2 SAVE "DrMISSCQL. SAV": STOP : REM DISK 



4 REM ADJUST HORIZONTAL 8, VERTICAL 
COORDINATES 
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5 XO=X0+SP: YO=YO+SP: RETURN 

6 YO=YO-SP: XO=XO+SP: RETURN 

7 XO=XO+SP: RETURN 

9 XO=XO-~SP; YO=YO+SP: RETURN 

io xo=xo-sp: yo=yo-sp: return 

X0=X0-SP: RETURN 
Y0=Y0+SP: RETURN 
Y0=Y0-SP: RETURN 
POP :PLAYER0$(YO) 
REM MOVE PLAYER'S 



legsi*:goto 

LEGS 



500 



11 
13 
14 
15 
29 

30 Z=Z+l:POKE HP0SP0,X0:IF Z<4 THEN PL 
AYERO* ( YO ) =LEGS 1 $ : RETURN 

31 1^ Z<7 THEN PLAYER0$(Y0)=LEGS2*:RET 
URN 

32 PLAYER0*(Y0)=LEGS3$: IF Z=9 THEN Z=0 
: RETURN 

33 RETURN 



/ 40 RETURN 

4i xo=xoa: 



YO=YOA : POKE H I TCLR , 1 : RETURN 



42 XO=XOA: Y0=Y0A:P0KE HITCLR, 1 : RETURN 



44 xo=xoa: yo=yoa:poke hitclr, 1:return 



49 REM MISSILE TO PL f)V FIELD 

50 RETURN 

51 GOSUB 190: RETURN 

52 GOSUB 190." RETURN 

53 GOSUB 190: RETURN 

54 GOSUB 190: RETURN 

V 60 REM E ND OF COLLISIONS 



65 MX0=MX0+MS0: MY0=MY0+MS0: RETURN 

66 MY0=MY0-MS0: MX0=MX0+MS0: RETURN 

67 MX0=MX0+MS0: RETURN 

69 MXO=MXO-MSO: MY0=MY0+MS0: RETURN 

70 MX0=MX0-MS0: MY0=MY0-MS0: RETURN 

71 MXO=MXO-MSO: RETURN 

73 MYO=MYO+MSO: RETURN 

74 MYO=MYO-MSO: RETURN 



190 POKE 
TCLR, 1 : RETURN 



hposmo,o 



D1=0:FIRE0=0:P0KE HI 



199 REM 



MAIN LOOP 
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^ 200 


? "POPF=" 3 PEEK (POPF) , 


"M0PF=" 


; PEEK ( "\ 


MOPF ) : GOSUB PEEK ( POPF ) +40 


: GOSUB 


PEEK(M 


OPF) +50 








201 


Y0A=YO: X0A=X0: GDBUB PEEK 


(JOYSTICK) 


:bosub movelegs 






— ,. — ,i 


260 


REM 








270 


REM 








280 


REM 








290 


REM 








300 


POKE SD1,P1:F0KE DV1, 


Dl: 


POKE 


SIZEM 



„ PEEK (RANDOM) 

301 IF PEEK(BUTT0N0)=0 AND PEEK(JOYSTI 

CK)<>15 THEN MOVEO=PEEK (JOYSTICK) : FIRE 

0=FIRE0+1 

305 IF FIREO=0 THEN GOTO 200 

315 IF FIRE0=1 THEN MX0=X0+3: MY0=Y0+7: 

D I RO=MO VEO : F I REO=F I REO+ 1 : D 1 = 1 5 

320 IF FIREOM THEN GOSUB DIRO+60 

330 D1=D1-1:IF DK1 THEN D1=0 

335 MISSILES*=BUFFER*:POKE HP05M0,MX0: 

MISSILES* (MYO) =M I MABEO* 

499 GOTO 200 

600 graphics ortrap 610: for 1=1 to 128 
:? 15" ";asc(PLAYER0*(D ) :next i : stop 

610 END 

1999 REM SETUP ROUTINES FOLLOW. 

2000 GOSUB 1 0000: REM MISC. INITIALI- 
ZAT1 

2005 GRAPHICS 7: REM S£7 BR. MODE 
BEFORE PMG SETUP' 




' 



2010 GOSUB 12000: REM DRAN PL AY FIELD 
;015 GOSUB 11 OOP: REM PMG SETUP 
2020 GOSUB 13000: REM PLAYER COLORTTND 
SCREEN POSITION 

2025 GOSUB 14000: REM DISPLAY MESSAGE 
2130 RETURN 

2999 REM ERROR CORRECTION ROUTINE 

3000 IF X0>210 THEN X0=210 
3010 IF X0<39 THEN X0=39 
3020 IF Y0<1 THEN Y0=1 
3030 IF Y0M2B THEN Y0=128 
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3035 


Z=0 








3040 


MX0=XO:MY0 


=Y0 




3050 


D1=0 








3060 


FIRE0=0 






3080 


TRAP 


3000: 


GOTO 


300 


10000 REM 


MISC. 


INITIflLI 



10000 REM MISC. INITIALIZATION 

1 0050 J OYBT I CK=632 : HP0SP0=53248 : PR 1 0R= 

623 : M0VELE6S=30 : SP= 1 : PR=8 : BUTT0N0=644 : 

SETSOUND= 1 000 : S0=53760 

1 0060 BUTT0N0=644 : SETSOUND= 1 000 : S0=537 

60:DV0=53761:HP0SM0=53252:HP0SM0=53252 

: MS0--6 , 

1 0070 Pi = 10 : Dl =0 : SD 1 =53762 : DV 1 =53763 : S 
I ZEM=53260 : RANDOM=53770 : P0PF=53252 : MOP 
F=53243:HITGLR=53278:P0KE HITCLR, 1 




10900 RETURN 

10999 REM PM6 SETUP ROUTINE 

11000 DIM FILLER1*<1) , FILLER2*( (INT (AD 
R ( F I LLER 1 * ) / 1 024 ) + 1 ) * 1 024-ADR ( F I LLER 1 * 
)-l) 

11010 DIM BUFFER* (384) , MISSILES* (128) , 

PLAYERO* (128), PLAYER 1 * ( 1 28 ) , FLAYER2* ( 1 

28) , PLAYER3*(128) 

11020 BUFFER*=CHR*(0) 

1 1 030 BUFFER* ( 384 ) =CHR* ( ) 

1 1 040 BUFFER* ( 2 ) =BUFFER* 

1 1 045 M I SS I LES*=BUFFER* : PLAYERO*=BUFFE 

R* : PLAYER 1 *=BUFFER* : PLAYER2*=BUFFER* : P 

LAYER3*=BUFFER* 

11050 DIM LEGS1*(17) ,LEGS2*(17) , LEGS3* 

(17) 

11060 FOR 1 = 1 TO 17: READ A: LEGS1* ( I , I ) 

=CHR*(A) :NEXT I 

11065 FOR 1=1 TO 17: READ A: LEGS2* ( I , I ) 

=CHR*(A) :NEXT I 

11067 FOR 1 = 1 TO 17: READ A." LEGS3* ( I , I ) 

=CHR*(A) :NEXT I 

11070 DIM MIMAGEO*( 1) :MIMAGE0*=CHR*(3) 

11080 POKE 54279, ADR (BUFFER*) /256: REM 

DTELL ANTIC WHERE START OF PM MEMORY I 

S 

11085 POKE 559, 46: REM DOUBLE LINE RES. 
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11090 POKE 53277, 3: REM TURN ON PMG 
11110 POKE PRIOR, PR 

11299 RETURN 

11300 DATA 0,0,0,28,28,8,28,58,89,24,6 
0, 36, 36, 102, 0, 0, 

11310 DATA 0,0,0,28,28,8,28,58,89,24,4 
0, 76, 68, 68,0,0, 

11320 DATA 0,0,0,28,28,8,28,58,89,24,5 
6,72, 132, 130,0,0,0 
11999 REM DRAN PLflYFIELV 
f 12000 8ETC0L0R 2, 3, 4: COLOR 1 

12010 PLOT 0,0:DRAWTO 159,0."DRAWT0 159 
,79:DRAWT0 0,79:DRAWT0 0,0 
12015 COLOR 2 

12020 PLOT 80,61:DRAWT0 80, 79: PLOT 0,6 
0: DRAWTO 30, 60: DRAWTO 30,79 
12025 COLOR 3 

12030 PLOT 52, 60: DRAWTO 52,45:DRAWT0 1 
10, 45: DR A WTO 1 10, 60: DRAWTO 137, 60: DRAW 
TO 137, 45: DRAWTO 110, 45: PLOT 159,32 
12040 DRAWTO 110, 32: PLOT 80, 45: DRAWTO 
80, 20: PLOT 130, 16: DRAWTO 130, 14: DRAWTO 
127, 14:DRAWT0 127, 16:DRAWT0 130,16 






" 



12050 PLOT 43,0: DRAWTO 43, 30: PLOT 52,4 
5:DRAWT0 22,45:DRAWT0 22,13:PL0T 103,0 
: DRAWTO 103, 17: POKE 559, 34: RETURN 



12999 REM 
POSITION 



SET PLAYER COLOR AND 



/ 13000 X 0=1 75 "\ 
L 13010 Y0=80 J 



X 0=175 
Y0=80 
POKE 704, 



88 



13020 

13030 POKE 53248, XO: REM POKE HORI- 
ZONTAL VALUE INTO HORIZONTONAL 
POSITION REBISTER. 

13040 PLAYER0*(Y0)=LEGS1*:REM PUT 
IN ABE INTO PROPER BYTE OF PLAYERO. YO 
DETERMINES VERTICAL POSITION 

13050 RETURN, , 

"Collision Demo." : FOR I 
NEXT PAUSE: RETURN 



C 14000 ? 

\toioo: 



3 
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Save the program and then run it. Note: I suggest you push the RESET 
button each time before you run the program; this will ensure that the PMG 
image appears correctly when the program first starts. As you move the player 
against the various walls of the maze, notice the values that appear in POPF. 

Next try firing the missile in various directions. Notice that sometimes the 
missile will hit a wall. When this happens, the missile sound stops and the 
missile disappears. The player can now immediately fire another missile. 

Sometimes the missile will go right "through a wall." That's because the 
missile is moving in increments of 6. Actually, the missile is "hopping over the 
walls"— it really never touches the wall— hence there is no collision. This could 
be fixed by making the walls thicker or the missile bigger. Or the missile 
coordinates could be adjusted by 1 instead of 6. Of course, then the missile 
would probably move too slowly for most purposes. 

Yet another approach would be to use an assembly language routine to 
move the missile.* In the programs in this book we'll simply let the missile pass 
through walls. In a game situation, this effect is good because you never know 
when one of your missiles will be "super-charged" and capable of passing 
through a wall. 

SLOW PLAYER MOVEMENT 

Notice that the player moves rather slowly. That's mainly because we are 
constantly peeking at and printing the values contained in the collision regis- 
ters. You can speed up the player's movement considerably by deleting 
?P0PF=";PEEK(P0PF) and ?M0PF=";PEEK(M0PF) in line 200. 

Of course part of the reduction in the player's speed results because the 
main loop is becoming more complicated. Remember, we are doing quite a bit 
in this little BASIC program. We have created: 

• Vertical, horizontal, and diagonal movement 

• Leg animation 

• Missile firing and movement in eight directions 

• Random missile-size selection 

• Explosive missile sound 

• Player and missile collison detection. 



*Watch for my next book on advanced PMG techniques. In it I'll show you how to use machine 
language subroutines to speed up your PMG programs. 
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But with player-missile graphics, once we have come this far, it's easy to add 
even more "features." 



ADDING MORE FEATURES 

Let's try something a little different. Let's pretend that the COLOR 1 playfield has 
an electrical charge that will zap our player if he touches it. To produce the 
"zapping effect," let's produce a strange sound and flash several colors through 
the player when he touches playfield 1. Furthermore, let's set our player to a 
random new color and then put him back to his starting location. The code to 
do this is relatively simple and won't slow down the main action. That's 
because the code will not be in the main loop but in subroutines that will 
execute only when a collision occurs. 

Here's the new code to "zap" the player when he touches the COLOR I 
playfield. Change line 41 to: 

41 X0=175:Y0=80: 
GOSUB 400: 

POKE 704,PEEK(RANDOM): 
PLAYERO$=BUFFER$: 
POKE HPOSPO.XO: 
POKEHITCLR.1: 
RETURN 

And add lines 400 and 410: 

400 FOR 1=0 to 100 STEP 2: 

POKE 704,1: 

SOUND 0,1,10,15: 

SOUND 1,1+50,10,15: 

NEXT I 
410 SOUND:RETURN 

Also change line 499 to line 390 so that line 390 reads "GOTO 200." 
As you can see the subroutine at line 400 rapidly moves different values 
into player 0's color register. This causes him to "glow." In the same loop we 
also include a nice sound effect with the aid of a couple of SOUND statements. 
(I used SOUND statements, here, rather than poking audio control registers, 
because SOUND statements are easier to use. Remember, speed is not so 
important here since we are not in the main loop. When a player is zapped, it's 
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natural for the action to stop. All attention is focused on the zapped player, 
anyway.) 

There you have it. Collision detection complete with a fancy routine to 
zap a player and move him back to his starting location if he hits a specific kind 
of playfield. 

In the next chapter we'll pull together everything you've learned so far 
and create "MAZEDUEL," a racing game in which two players compete for a 
dangerous but valuable "crystal." 




Programming a Game 



In this chapter I'll show you how to use the techniques you've learned to write 
an arcade-style game. It doesn't have the speed of a machine language pro- 
gram, but thanks to Atari's PMG it contains a lot of action-packed features: 
animated players, sound effects, missiles, lasers, collision detection, and flash- 
ing colors. And best of all, since you've come this far, you'll be able to modify it 
to your liking. Before you know it, you'll be creating your own original games! 



MAZEDUEL 

Let's call the game "Mazeduel" since two players will be fighting it out as they 
chase each other around a maze. I'll go over the rules of the game first and 
then discuss the programming techniques. 

Winning a round. The game will have rounds (sort of like a boxing match). 
In the upper right corner of the maze you'll see a magic crystal. If a player 
touches the crystal, an alarm will sound as the screen flashes different colors. 
The player who touches the crystal wins the round and is awarded five points. 
Both players will then be moved back to the starting box. 
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A player can also win a round by hitting the crystal with a missile. In this 
case, however, that player gets only one point. 

Firing missiles. Players can fire missiles at each other. Missiles contain a 
strange substance that causes players to instantly expand to double size if they 
are hit. If a player expands to double size, he stays that way until the other 
player gets zapped. 

If you are hit by a missile you will be zapped back to the starting box and 
enlarged to double size. You get one point for hitting another player with a 
missile. 

Maze walls. You must exercise extreme caution when moving around the 
maze. If you touch a maze wall, you are also zapped back to the starting box 
and enlarged to double size. In addition, the other player will gain a point. 

Beware of the crystal. The crystal is harmless — unless you try to win a 

round by touching it. When the crystal's defense system is activated, it may 
send out a storm of laser-type missiles. If you are quick enough though, you 
may be able to avoid the lasers. But ifyou don't, you will again be expanded to 
double size and zapped back to the starting box. Another penalty is that the 
other player will gain one point. The lasers destroy any part of the maze that 
they hit, but only stun players. As the maze starts to break up more and more, 
you will find it easier to sneak up on the crystal. 

It's possible for a player to escape from the maze and sneak up on the 
crystal while "offscreen." (I won't tell you how.) Be alert when hiding behind 
maze walls. Missiles fired by players sometimes penetrate walls! To fire a 
missile, move the player in the direction you want the missile to go and press 
the fire button. The first player to get ten or more points wins. You can start a 
new game by pressing your fire button. 

Selecting colors. At the beginning of each game, you can select the color of 
the playfield by pressing the SELECT key. Just keep pressing it (or hold it down) 
until you get a color you like. When you're ready to start the game, press the 
START key. 

To select colors for players, press the OPTION key. 

As usual, the complete listing appears at the end of this chapter. You may 
wish to load the program from the previous chapter, MISSCOLSAV, and then 
modify it to produce MAZEDUEL.SAV. I've made a lot of modifications, how- 
ever, and it may be just as easy to type it in from the start. 



~ 
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For maximum execution speed, don't type in any of the REM statements. 
I included them to help you understand the program (and to help myself keep 
track of what I was doing). 

Again, the subroutine beginning at line 2000 takes care of calling the 
various setup subroutines. Here are the setup subroutines along with their 
beginning line numbers: 

10000 Initialize Constants 

12000 Draw Playfield 

11000 SetupPMG 

13000 Specify player colors and initial position (off screen) 

5000 Allow users to select colors 

Note that line 10000 is no longera REM statement. If it were, the GOSUB 
10000 statement at line 2000 would produce an error if you were to delete the 
REM statements. 

In the 13000 subroutine, at line 1345, I poke PLAYER1S with the data in 
LEG1S. Remember, PLAYER1S is the PM memory area for our second player. 
PLAYER0S is the memory area for our first player. To simplify the programming, I 
made both players have exactly the same image. (They are easy to tell apart, 
because each has its own color.) 

Notice that in the subroutine starting at line 5000, 1 move the players onto 
the screen and display a message in the text window. Location 53279 tells me 
which of the console keys have been pressed. When 53279 contains a 6, I 
know the user has pressed the START key and it's time to return from this 
subroutine. 

Control then returns to the "executive" setup subroutine at line 2000. I 
call the subroutine at line 2000 an "executive" because it controls other sub- 
routines rather than carrying out any direct action of its own. After the last 
subroutine within the executive setup subroutine, control returns to line I. From 
there we jump to the main loop at line 200. 

CHECKING FOR COLLISIONS 

Lines 200 and 201 now check for the various collisions. Notice how easy this is. 
We simply call various subroutines. The subroutine called depends on the 
contents of the appropriate collision register. For example, look at the first 
statement in line 200: 
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GOSUB PEEK(P0PF)+100 

■ If the player to playfield collision register (POPF) contains a zero, meaning 
no collision, which subroutine will be executed? 

ANSWER 

The one at line 100 (0+100=100). 

So at line 100 we put a RETURN statement. Now, the magic crystal was 
drawn using COLOR 2. So the magic crystal is considered a "COLOR 2 play- 
field." 

■ Suppose player touches the crystal. Which subroutine will be executed? 

ANSWER 

The one at line 102 (2+100=102). 

The other collision detection subroutine calls work the same way. Slick, 
huh? And much faster than IF-statementsI* 



MOVING LEGS 

At line 204 we check to see if joystick has been moved. JO is now a variable 
initialized to 632, the memory location that contains the value forjoystick 0. If JO 
is not equal to 15 (upright joystick), then I add 1 to Z. Z will now be equal to 1. At 
this point, I GOSUB line 35 (34+Z will equal 35). Line 35 moves LEG1S data into 
PLAYER0S. The next time through the main loop, line 204 will call the sub- 
routine at line 36 (since Z will now be equal to 2). 

This is similar to the earlier leg movement routine. I modified the earlier 
routine to make it easier to handle the movement of two separate players. 

If the joystick is not moved, then control will pass to line 205. At line 205 1 
simply move the "standing still" image of player into PLAYER0S. I do a similar 
thing for player 1 at lines 206 and 207. 



*l'd like to thank my son, Dan Seyer, for suggesting this collision detection method. 
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CRYSTAL DEFENSE SYSTEM 

Control now passes to the crystal defense system at line 210. Notice that I am 
using the random number generator at location 53770. (RANDOM is initialized 
to 53770.) If RANDOM contains a number greater than 220 then we check to 
see if either of the players has entered the crystal's attack zone. We know a 
player is in the crystal's attack zone if its X coordinate is greater than 142 and its 
Y coordinate is less than 34. During game development, you can easily discover 
the coordinates for a specific location by positioning a player where you want 
him, hitting the break key, and then printing the coordinates. 

Why the check of the random number? Well, this way the crystal's 
defense system isn't perfect. Sometimes a player will be able to sneak past it 
and reach the crystal before it starts wildly firing lasers in all directions. By 
changing 220 to some other number, you can increase or decrease the proba- 
bility that a player will be able to sneak in and touch the crystal. The higher the 
number (up to 255) the better the player's chances will be. (By the way, 
location 53770 generates a random number between and 255.) 

If all conditions are satisfied, then the laser firing routine is activated 
starting at line 450. This is a fairly simple routine, but the results are quite 
dramatic. In this routine I use DRAWTO statements to create the lasers. A nice 
effect is produced by drawing the various random vertical coordinates. Again I 
used location 53770 to set a variable called VT to various values. VT is then 
used in the DRAWTO statement as the vertical coordinate. Notice that I use 
COLOR 1 when drawing the laser. The collision detection routine is already set 
up to detect a collision with anything drawn with COLOR I. So if the laser hits 
the player, zapo-whamo! After drawing a laser, I erase it by redrawing it using 
COLOR 0. 

After the crystal defense check at line 210, control passes on to the missile 
move routine at 300. 



MISSILE MOVE ROUTINE 

This routine is quite similiar to the one in the previous chapter, except that now 
we have to deal with two missiles. This can present a problem when two 
missiles are both fired at the same time. The binary image data for missile is: 



00000011 (or 3 in decimal) 

For missile 1, the binary data is: 
00001100 (or 12 in decimal) 



140 / Programming A Game 

Suppose both missiles happen to occupy the same byte in missile memory. 
(This will happen whenever MY0=MY1.) 

■ What if we move 00000011 into byte 22 of MISSILES and then immediately 
move 00001100 into that same byte of MISSILES? What will be the effect on 
missile 0? 



ANSWER 

Missile will disappear! That's because the zeros in the far right bit position 
of missile 1 will take the place of the 1's that were there before. 



Look again at the binary data: 

Missile 0: 00000011 
Missile 1: 00001100 

This can be solved with a machine language subroutine that addresses 
specific bits. That is, if we wanted to turn on missile 0, we would turn on only 
the two bits on the far right. But we would not move zeros into the other bits. 

In BASIC we cannot address specific bits. That is, we cannot move data 
only into certain bits, but not others. In BASIC we must deal in bytes. 

My solution to the problem was to "turn on" both missiles whenever 
both missiles happened to occupy the same byte in missile memory. I did this 
by initializing a variable called BMISSS to 15. Then at line 335 I check to see if 
MX0=MX1. If MX0=MX1, I jump to line 400 where I move 15 into MISSILES. 

■ Why does putting a decimal 15 into MISSILESS turn on both missilesS? 



ANSWER 



Because in binary, 00001100 + 00000011 = 00001111 and 00001111 = a decimal 

15. 



Now if MY0 does not equal MY1, the missiles are not destined to occupy 
the same byte in missile memory. Consequently, I move the missile data for 
each missile with separate statements in line 340. 

Yes, the IF-statements do slow things down. You're right if you're think- 
ing that this is a good place for a machine language subroutine. (Look for it in 
my next book on PMG.) 

After the missile data is moved into the proper byte of MISSILES, control 
returns to line 200, the first line of the main routine. 



" 
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TYPING IN THE PROGRAM 

The program listing appears at the end of this chapter. It may look long, but 
remember, a lot of it is a duplication of the code from the previous chapter. 

As I mentioned earlier, it's probably a good idea to omit all REM state- 
ments when typing in the program. It will require less memory this way and 
run faster. The program will fit into a 16K cassette system or a disk drive system 
with 24K. 

Since this program was designed for instructional purposes, more line 
numbers are used than actually needed. You can speed up the program 
somewhat by combining some lines. For example, line 330 could be combined 
with 335. But be careful in doing this. For example, don't try to combine two 
IF-statements. If you do, then the second IF-statement won't execute unless the 
first condition is true. For best results, I suggest you type in the program exactly 
as is. Then after you've saved a working copy, you can do your thing! Have fun. 
Here are some revision suggestions: 

1. Make the crystal more interesting by creating him with PLAYER2S. You 
can put PLAYER2S right on top of {or underneath) a playfield. 

2. You could create a three-colored crystal by combining PLAYER2S with 
PLAYER3S (see the next chapter for details). 

3. If you make the crystal with PMG, then you can make it glow by 
poking different values into the appropriate color registers. You could 
also easily animate it or change its size, with just a few statements. If 
you do this at line 450 (the laser firing routine), you won't slow down 
the main loop. That's because line 450 executes only when a laser is 
fired by the crystal. 

4. Using the other players, you might want to have various alien crea- 
tures pop up in the maze and block the movement of the main two 
players. 

5. You may wish to experiment with changing the players to different 
sizes at different times. Here are the size registers: 

Player Number Size Register 

53252 

1 53253 

2 53254 

3 53255 

To set a player's size, poke the appropriate register with 0,1,2, or 3 as 
follows: 
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Value to Poke 


Player Size 


into Register 


Normal 


0or2 


Double 


1 


Quadruple 


3 



So for normal player size, poke the appropriate register with zero or 2. 
For double player size, poke it with 1. For quadruple player size, poke it 
with 3. 

6. For faster action, you might want to try your hand at converting part of 
the program to machine language. MAZEDUEL is written entirely in 
BASIC. Again, look for my next book on PMG for hints on how to do 
this! In the meantime, I suggest you keep reading your favorite maga- 
zine for ideas. My favorites (in alphabetical order) aK: Analog, Antic, 
Byte, Compute, Creative Computing, and Micro. 

Happy hacking. 

Congratulations. You've just about finished this book. By now, you've 
mastered most of the fundamentals of PMG — one of the most powerful and 
least understood features of the Atari computer. 

In the next chapter, I'll wrap things up (at least for now), by discussing a 
few additional PMG odds and ends. 

I TRAP 3000:eOSUB 2000: GOTO 200 

2 save "d: mazeduel. sav": stop 

5 xo=xo+sp: yo=yo+sp: return 

6 yo=yo-sp: xo=xo+sp: return 

7 xo=xo+sp: return 

9 xo=xo-sp: yo=yo+sp: return 

10 x0=x0-sp: y0=y0-sp: return 

II xo=xo-sp: RETURN 

1 3 Y0=Y0+SP : RETURN 

14 Y0 = Y0--5P: RETURN 

15 RETURN : REM POP : PLAYERO* (YO) =LEGS1 
* : POKE DVO , : GOTO 2 1 

16 X1=X1+SP: Y1=Y1+SP: RETURN 

17 yi=yi-sp: X1=X1+SP: RETURN 
10 X1=X1+SP: RETURN 

20 X 1 =X 1 -SP : Y 1 =Y 1 +SP : RETURN 

21 X1=X1-SP: yi=yi-sp:return 

22 X1=X1-SP: RETURN 
24 Y1=Y1+SP: RETURN 
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25 Y1=Y1-BP: RETURN 

26 RETURN : REM POP : PLAYERO* (YO) =LEGS1 

*:poke dvo,o:goto 210 

29 rem move legs of plover 

35 playero* ( yo ) =legs 1 * : return 

36 playero* (yo) =legs2*: return 

37 playero* <y0)=le6s3*: z=0: return 
49 rem move legs of plover 1 

55 player 1 * ( y 1 ) =legs 1 * : return 

56 PLAYER1*(Y1)=LEGS2*: RETURN 

57 PLAYER 1 * ( Y 1 ) =LEGS3* : W=0 : RETURN 

65 MXO=MXO+MSO: MYO=MYO+MSO: RETURN 

66 MYO=MYO-MSO: MXO=MXO+MSO: RETURN 

67 MXO=MXO+MSO: RETURN 

6 9 MXO=MXO-MSO: MYO=MYO+MSO: RETURN 

70 MXO=MXO-MSO: MYO=MYO-MSO: RETURN 

71 MXO=MXO--MSO: RETURN 

73 MYO=MYO+MSO: RETURN 

74 MYO=MYO-MSO: RETURN 

84 REM OB JUST MISSILE 1 

85 MX 1 =MX i+MSO: MY 1=MY1+MS0: RETURN 

86 MY1=MY1-MS0: MX1=MX1+MB0: RETURN 

87 MX 1=MX1+MS0: RETURN 

89 MX 1 =MX 1 -MSO : MY 1 =MY 1 +MSO : RETURN 

90 MX 1 =M X 1 -MSO : MY 1 =MY 1 -MBO : RETURN 

91 MXi=MX 1 -MSO : RETURN 

93 MY 1=MY1+MS0: RETURN 

94 MY 1=MY1 -MSO : RETURN 

98 REM COLLISIONS 

99 REM PLOVERO TO PLOV FIELD 

100 RETURN 

101 Bl=Sl+l:GOSUB ZAP:PLAYERO*=BUFFER* 
: PLAYERO* ( YO ) =LEGS 1 * : GOSUB 5500 : RETURN 

102 S0=S0+5:G0T0 660: REM PLOVERO HITS 
CRYSTAL/ 

103 Sl=Sl+l: GOSUB zap:playero*=buffer* 
: PLAYERO* ( YO ) =LEGS 1 * : GOSUB 5500 : RETURN 



104 RETURN 

105 RETURN 

106 RETURN 

107 Sl=Sl+l: GOSUB ZAP:PLAYERO*=BUFFER* 
: PLAYERO* (YO) =LEGS1*: GOSUB 5500: RETURN 
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108 REM PLOVER 1 TO PLOY FIELD 

109 RETURN 

110 S0=S0+1: GOSUB ZAP2:PLAYER1*=BUFFER 
* : PLAYER 1 * ( Y 1 ) =LEGS 1 * : GOSUB 5500 : RETUR 
N 

111 S1=S1+5:G0T0 660: REM PL0YER1 HITS 
CRYSTAL.' 

112 S0=S0+1: GOSUB ZAP2:PLAYER1*=BUFFER 
* : PLAYER 1 * < Y 1 ) =P 1 I MAGE 1 * : GOSUB 5500 : RE 
TURN 

113 RETURN 

114 RETURN 

115 RETURN 

116 SO=S0+l: GOSUB ZAP2: PLAYER 1*=BUFFER 
$ : PLAYER 1 * ( Y 1 ) = LEGS 1 * : GOSUB 5500 : RETUR 
N 

117 REM MISSILE TO PLOYFIELD 

118 RETURN 

119 FIREO=0: GOSUB OFF: MX0=0: RETURN 

120 FIREO=0: GOSUB OFF: MXO=0: POKE HITCL 
R,0:SO=SO+l:GOTO 660: REM MISSILE HITS 

CRYSTAL.' 

121 RETURN 

122 RETURN : GOSUB ZAP2: RETURN 

124 REM MISSILE 1 TO PLOYFIELD 

125 RETURN 

126 FIRE1=0: GOSUB OFF: MX 1=0: RETURN 

127 FIREO=0: GOSUB OFF: MX 1=0: POKE HITCL 
R,0:Sl=Sl+l:GOT0 660: REM MISSILE HITS 

CRYSTAL/ 

128 RETURN 

129 RETURN : GOSUB ZAP: RETURN 

130 REM MISSILE J TO PLOVER 

131 RETURN 

132 GOSUB ZAP:S1=S1+1:FIRE1=0:MX1=0:G0 
SUB 5500: RETURN 

133 RETURN 

134 RETURN 

135 GOSUB 85: RETURN 

136 REM MISSILE. TO PLOVER 1 

137 RETURN 

138 RETURN 

139 GOSUB 530:so=so+i:fireo=o:mxo=o:go 
SUB 5500: RETURN : REM MO HITS PLOVER J 






Typing in the Program / 145 

140 RETURN 

141 RETURN 

142 RETURN 

1 70 M I SS I LES*=BUFFER* : D0=0 : D 1 =0 : RETURN 
:REM ERASE MISSILE AND SOUND 

199 REM MAIN LOOP 

200 GOSUB PEEK (POPF) +100: GOSUB PEEK(P1 
PF)+109:B0SUB PEEK (MOPF) +118: GOSUB PEE 
K(M1PF)+125 

201 GOSUB PEEK (Ml PL) +131: GOSUB PEEK (MO 
PD+137 

202 poke hitclr, 1: y1a=y1:x1a=x1: xoa=xo 
:yoa=yo:rem clear collision register/ 
SAVE PLAYER coordinates 

203 GOSUB PEEK (JO) : GOSUB PEEK ( J 1 ) +1 1 : P 
OKE HPOSPO, XO:POKE HP0SP1 , X 1 : REM . 

ADJUST COORDINATES/POKE HOR. POSITION 

204 IF PEEK(J0X>15 THEN Z = Z + 1: GOSUB 3 
4+Z:G0T0 206: REM MOVE LEGS 

205 PLAYER0*(Y0)=LEG51$ 

206 IF PEEK(J1)<>15 THEN W=W+l: GOSUB 5 
4+W:G0T0 210: REM MOVE LEGS 

207 PLAYER1*(Y1)=LEGS1* 

210 IF PEEK (RANDOM) >220 THEN IF X0>142 
AND Y0<34 OR Xl>142 AND YK34 THEN GO 
SUB 450 

299 REM MISSILE MOVE ROUTINE 

300 POKE SIZEM, PEEK (RANDOM) : POKE SDO,P 
o:poke DVO,DO:POKE SD1,P1:P0KE DV1,D0 

301 IF PEEK(BUTTQNO>=0 AND PEEK(J0)<>1 
5 THEN MOVE0=PEEK(JO) :FIRE0=FIRE0+1 

302 IF PEEK < BUTTON 1)=0 AND PEEK(J1)<>1 
5 THEN M0VE1=PEEK(J1) :FIRE1=FIRE1+1 
305 IF FIREO=0 AND FIRE 1=0 THEN 200 
307 POKE HP0SM0,MX0:P0KE HP0SM1,MX1 
315 IF FIRE0=1 THEN MX0=X0+3: MY0=Y0+7: 
D I RO-MOVEO : F I REO=F I RE0+ 1 : D0= 1 5 : REM SET 
INITIAL POSITION OF MISSILES 

317 IF FIRE1=1 THEN MX 1=X 1+3: MYl=Yl+7: 
DIRl=M0VEl:FIREl=FIREl+l:D0=15 

320 IF FIREOM THEN GOSUB DIRO+60 

321 IF FIRE1M THEN GOSUB DIR1+S0 
330 D0=D0-2: IF D0< 1 THEN D0=0 
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335 IF MY0=MY1 THEN 400 

340 MISSILES*=BUFFER*:MISSILES*(MYO)=M 

I MAGEO* ! MI SSI LES* ( MY 1 ) =M I MAGE 1 * 

399 GOTO 200 

400 MISSILES*=BUFFER*:MISSILE5*<MY0) =B 
MISS*: GOTO 200: REM IMPORTANT: TURN ON 
BOTH MISSILES 

450 FOR 1=15 TO 1 STEP -1 : VT=PEEK (RAND 

0M)/2.7:S0UND 3, I , 4, 15: COLOR 1 : PLOT 13 

2, 16:DRAWT0 90, VT 

455 PLOT 132, 16:DRAWT0 159, VT 

460 COLOR 0:PLOT 132, 16: DRAWTO 90,VT:P 

LOT 132, 16:DRAWT0 159,VT:NEXT I : SOUND 

3,0,0,0: GOSUB 700: RETURN 

499 GOTO 200 

500 GOSUB OFF: MX 1=0: POKE MOPL,l:POKE M 
1PL,2:FIRE0=0 

510 POKE DVO,0:P0KE SD 1,0: FOR 1=2 TO 2 

55 STEP 2: POKE 704, I: SOUND 0, I, 14,1 4: N 

EXT I: POKE 704,K0L0R0 

520 X0=50: Y0=7B:P0KE 53248, XO: PLAYERO* 

=BUFFER*: PLAYERO* (YO) =LEGS1*: RETURN 

530 GOSUB OFF: MXO=0: POKE M1PL,1:P0KE M 

OPL , 2 : F I RE 1 =0 : F I REO=0 

540 POKE DVO,0:POKE SD1,0:F0R 1=2 TO 2 

54 STEP 2: POKE 705, I! SOUND 0,I,14,15:N 

EXT J. : POKE 705,K0L0R1 

550 Xl=62: Yl=78: PLAYER1*=BUFFER«: PLAYE 

R 1 * ( Y 1 ) =LEGS 1 * : POKE HPOSP 1 , X 1 

560 RETURN 

600 TRAP 610: FOR 1=1 TO 128."? I;"= "jA 

SC(BMISS*(I. ) ) :NEXT I : STOP :REM GO HERE 

TO LOOK QT 7)Prtf) IN PM MEMORY. 
610 END 

660 FOR J=l TO 20: FOR 1=1 TO 5:SETC0L0 
R 4, J, J+l: SOUND 0, 1*10-7, 10, 1*2: NEXT I 
:NEXT J: POKE M0PL,2:P0KE Ml PL, 2 

66 1 PLAYER 1 *=BUFFER* : PLAYERO* < YO ) =LEGS 
1*: Xl=62: Y 1=78: POKE 53249, X 1 : ROUND=ROU 
ND+1 

662 X0=50:Y0=78: GOSUB 5500: PLAYERO*=BU 
FFER*: PLAYERO* (Y0)=LEGS1*: POKE 53248, X 
: SETCOLOR 4 , HUE , LUM '. RETURN 
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700 REM CRYSTAL 

710 COLOR 2:PLQ" 

PLOT 134, 12: DRAWTO 134,18 



710 COLOR 2: PLOT 131 , 15: DRAWTO 137,15 



720 


PLOT 1 3 


;i,i 


2: DRAWTO 137, 


is: PLOT 


, 18: 


DRAWTO 


137 


', 12:C0L0R 1 




730 


RETURN 








900 


REM 








910 


REM 








920 


REM 








1900 PLAYERO*= 


BUFFER*: Y0=12 


8: XG-80 


:60T0 190 








2000 GOSUB 


10000:REM initialize 


CONi 


>TANTS 








2005 GRAPHICS 


7: REM GR.MODE 


BEFORE 



131 



X=0 



PMG 



2007 GOSUB 12000." REM DRAM PLAY FIELD 

2010 GOSUB 1 1000: REM PMGSETUP 

2030 GOSUB 13000: REM SCREEN POSITION 

2040 GOSUB 5000: REM SELECT COLOR 

2050 RETURN 

2080 IF MYK1 OR MY 1>1 28 THEN MYl = i:PO 

KE 53253, 0: FIRE 1=0: SP=3: GOTO 2100 

2085 IF M X 1 < O OR M X 1 > 1 50 THEN MX 1 = 10 : F 

I RE 1=0: GOTO 2100 

2087 IF MXCKO OR MX0>150 THEN MX0=10:F 

I RE 1=0: GOTO 2100 

2090 IF MYO< 1 OR MY0M28 THEN MYO = YO:P 

OKE 53252 , : F I REO=0 : GOTO 2 1 00 

2095 IF MYK1 OR MY1>128 THEN MY1=Y1:P 

OKE 53252 ,, : F I REO=0 : GOTO 2 1 00 

2099 ? "GOOF NO. " ; PEEK ( 195) ? "SEE LINE 
NUMBER " ; PEEK (186) +256*PEEK (187) 

2100 DO=0:TRAP 2080: GOTO 200: REM PEEK ( 
187) *256+PEEK ( 186) 

3000 IF X0>210 THEN X0=210:REM CORRECT 

PLAYER COORDINATES 
3010 IF X0<39 THEN X0=39 
3020 IF Y0< 1 THEN Y0=1 
3030 IF Y0M28 THEN Y0=128 
3040 MX 0=0 : MY0=Y0 : MX 1 =0 : MY 1 =Y 1 
3050 do=o:di=o:rem turn off MISSILE 

SOUND 

3060 FIREO=0: FIRE 1=0: REM TURN OFF FIRE 
FLAG 
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3070 Z=0:REM RESET LEG MOVEMENT 

COUNTER 

3080 TRAP 3000: GOTO 210 

4000 RETURN : POKE 20,0 

4050 ? CHR*(125) : ? " 

5 11-Y: SOUND 0, Y+PEEK(20)+5, 14, 10: GOTO 

4010 

5000 ? "PRESS SELECT TO CHANGE SCREEN 

COLOR, OPTION TO CHANGE PLAYER COLOR, 

START TO START GAME" 
5005 X0=30: X 1=62: POKE HPOSPO, XO: POKE H 
POSP 1 , X 1 

5015 IF PEEK (53279) =5 THEN GOSUB 5200 
5020 IF PEEK (53279) =3 THEN GOSUB 5300 
5025 IF PEEK (53279) =6 THEN SETK=SETK.:R 
ETURN 
5030 GOTO 5015 

5199 REN CHANGE SCREEN COLORS 

5200 LUM=LUM+1 

5210 IF LUMM4 THEN LUM=0: HUE=HUE+1 
5220 IF HUE > 15 THEN HUE=0:LUM=0 
5230 SETCOLOR 4,HUE,LUM 

5299 REM CHANGE PLAYER COLOR 

5300 K0L0RO=K0L0R0+2 : KOLOR 1 =KOLOR 1+2:1 
F K0L0R0>254 THEN KOLORO=0 

5305 IF K0L0R1>254 THEN K0L0R1=0 

5310 POKE 704, KOLORO: POKE 705, KOLOR 1 :R 

ETURN 

5500 ? CHR*(125):? " ROUND # 

"; ROUND:? :? "PLAYER 1 = ";S0;" 

PLAYER 2 » "5 Si: SOUND 0,255,14,15 

5510 IF S0>9 THEN ? :? "PLAYER 1 WINS" 

:GOTO 5540 

5520 IF Sl>9 THEN ? i? "PLAYER 2 WINS" 

:GOTO 5540 

5530 RETURN 

5540 POP :? :POKE 82,0:? "PRESS THE FI 

RE BUTTON FOR ANOTHER GAME" 

,0,0: SOUND 1,0,0,0 

5550 IF PEEK(BUTTONO)=0 THEN 5560 

5552 IF PEEK ( BUTTON 1 ) =0 THEN 5560 

5555 GOTO 5550 

5560 POKE 82, 2: RUN 

10000 KOLORO= 163: KOLOR 1=83 



" 
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10020 X0=52: Y0=78: SF-3: XI =67: Yi=78: mxo 

=6: MY0=61 : MX 1=0: MY 1=71 : M0PL=532S6:SD0= 

53760: DV0=53761 : SD 1=53762: DV 1=53763 

10025 P0=50:P1=53 

10030 REM POKE 53248, XO: PLAYERO* (YO) =L 

EGS 1 * : POKE 53249 , X 1 : PLAYER 1 * ( Y 1 ) =LEBS 1 

* 

1 0040 POKE 53252 , : POKE 53253 , X 1 +3 

10050 J 0=632: J 1=633: HP0SP0=53248: HPOSP 

1 =53249 : HP0SM0=53252 : HPOSM 1 =53253 : BUTT 

DN0=644 

1 0055 BUTTON 1 =645 : MS0=8 

10060 RAND0M=53770:SIZEM=53260 

10100 HITCLR=53278:P0KE 53278, 1 : P0PF=5 

3252: P1PF=53253: M0PL=53256: M0PF=53248: 

M 1 PL=53257 : M 1 PF=53249 

10110 PRI0R=623:R0UND=l:DIM STRING* (12 

8) : ZAF-500: ZAP2=530:0FF=170 

10200 POKE HITCLR, l:REM CLEARS 

COLL IS IOC REGISTERS 

10998 RETURN 

11000 DIM FILLER1*(1) , FILLER2*( (INT (AD 

R(FILLER1*)/1024)+1)*1024-ADR(FILLER1* 

)-l) 

11010 DIM BUFFER* (384) , MISSILES* (128) , 

PLAYERO* ( 128) , PLAYER1* ( 128) , PLAYER2* ( 1 

28) ,PLAYER3*(128) 

11020 BUFFER*=CHR*(0) 

1 1 030 BUFFER* ( 384 ) =CHR* ( ) 

1 1 040 BUFFER* ( 2 ) =BUFFER* 

1 1 045 M I SS I LES*=BUFFER* : PLAYERO*=BUFFE 

R*: PLAYER1*=BUFFER*: PLAYER2*=BUFFER*: P 

LAYER3*=BUFFER* 

11050 DIM LE6S1*(17) ,LEGS2*(17) , LEGS3* 

(17) 

11055 RESTORE 11300 

11060 FOR 1=1 TO 17: READ A: LEGS1* ( I , I ) 

=CHR*(A) :NEXT I 

11065 FOR 1=1 TO 17: READ A: LEGS2* ( I , I ) 

=CHR*(A) :NEXT I 

11067 FOR 1=1 TO 17: READ A: LEGS3* ( I , I ) 

=CHR*(A) :NEXT I 

11069 DIM MIMAGE0*(1) :MIMAGE0*=CHR*(3) 
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11070 DIM MIMAGE1*(1 > :MIMAGE1*=CHR*<12 
) 

11071 DIM BMISS*(1) :BMISS*=CHR*(15) : RE 
M BOTH MISSILES "ON" 

11072 POKE 704,K0L0R0:REM SET COLOR OF 
PLftVERO 

11075 POKE 705,K0L0R1:REM COLOR PLAYER 

1 

11080 POKE 54279, ADR (BUFFER*) /256: REM 

SPECIFY START OF PM MEMORY 

11085 POKE 559, 46: REM DOUBLE LINE RES. 

11090 POKE 53277, 3: REM TURN ON PMG 

11100 POKE 53260, 5: REM WIDTH/MISSILES 

11110 POKE PRIOR, 2: REM SETS PRIORITY 

REGISTER 

11120 POKE HITCLR, l:REM CLEAR 

COLLISION REGISTERS 

11290 RETURN 

11300 DATA 0,0,0,28,28,8,28,58,89,24,6 

0, 36, 36, 102, 0, 0, 

11310 DATA 0,0,0,28,28,8,28,58,89,24,4 

0,76,68,68,0,0,0 

1 1 320 DATA O , , , 28 , 28 , 8 , 28 , 58 , 89 , 24 , 5 

6,72, 132, 130,0,0,0 

11330 DATA 0,0,0,120,56,16,56,116,176, 

48 , 50 , 60 , 64 , 192,0, , O 

11999 REM BRAN PLAYF1ELB 

12000 POKE 752, 1 : SETCOLOR 4,7,6 
12005 ? " MAZEDUEL" 

12010 COLOR l:PLOT 0,0".DRAWTO 159,0:DR 

AWTO 159,79:DRAWT0 30,79 

12015 COLOR 3: DRAWTO 0,79:DRAWT0 0,60: 

REM STARTING BOX 

12017 COLOR l:DRAWTO 0,0 

12020 PLOT 80,61:DRAWT0 80,79 

12025 COLOR 3: PLOT 1,60:DRAWT0 30,60:D 

RAWTO 30, 78: COLOR 1 : REM STARTING BOA 

12030 PLOT 52,60:DRAWT0 52,45:DRAWT0 1 

10,45:DRAWT0 1 10, 60: DRAWTO 137, 60: DRAW 

TO 137, 45: DRAWTO 110, 45: PLOT 159,32 

12040 DRAWTO 110, 32: PLOT 80, 45: DRAWTO 
80,20 

12041 BOSUB 700: REM DRAM CRYSTAL 
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12050 plot 43,0:drawt0 43, 30: plot 52,4 
5 : drawto 22 , 45 : drawto 22,13: plot 1 08 , 
: drawto 108, 17: poke 559, 34: return 
13000 xo=o:xi=o:rem horiz. player pos. 
13010 y0=78:rem vertical player pos. 

13015 Yl=78 

1 3020 POKE 704 , KOLORO : POKE 705 , KOLOR 1 : 

REM INITIAL COLOR 

13025 POKE MOPL,0:POKE M1PL,0:REM SET 

NIBTH OF PLAYERS 

13030 POKE 53248, XO: POKE 53249, X 1 : REM 

SET HORIZONTAL POSITION OF PLAYERS 

13040 PLAYER0*(Y0)=LEGS1*:REM PUT DATA 

IN PM MEMORY 
13045 PLAYER1*(Y1)=LE6S1*:REM PLAYER2 
13050 RETURN 



• 









' 







Odds and Ends 



Great! You've mastered the fundamentals of PMG and have seen how it can be 
used to develop a two-player, arcade-style game. In this chapter you'll learn 
some additional programming kinks. 






FIVE Pt>\YERSI 

So far I've said that you can create up to four players and that each player has a 
missile. Well, as you'll soon see, it's possible to have five players. 

There is a trade-off, though; you have to give up all of your missiles. In 
other words, if you want, you can use the missile memory area as a fifth player. 
To do that you simply add 16 to the value you would normally poke into the 
priority register. 

Using the Priority Register. Remember the priority register? It is location 623. 
You set various display priorities by poking either a 1, 2, 4, or 8 into location 623. 
|To review, see "Setting Display Priorities" in Chapter 5.) 

Suppose you want all players to appear in front of all playfields. To set up 
this display priority, you would normally poke a 1 into location 623. But if you 
want to turn the missiles into a fifth player, you would poke 17 into 623 (1+16). 

153 
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To help you keep track of what you're doing you might want to write the code 
like this: 

PRIOR=623 
POKE PRIOR, 1 + 16 

■ Suppose you want your normal player (players through 3) to appear 
behind all playfields. The usual practice would be to poke 4 into location 
623. But suppose you want a fifth player. Assuming PRIOR is initialized to 
623, how would you code this? 



ANSWER 

POKE PRIOR.4+16 (or POKE PRIOR.20) 



Setting the Fifth Player's Color. To specify the color you want for the fifth 
player, poke a number from to 254 into location 71 1 . (To review, see "Specify- 
ing Player Color" in Chapter 4.) 

Moving the Fifth Player. Although some PMG programmers may have 
problems with vertical movement, it will be easy for you! Just use the same 
method you learned earlier. Here's an example: 

MISSILES$(Y4)=LEGS1$ 

This statement will cause the image contained in LEGSIS to appear on 
the screen at whatever vertical location is specified by Y4. (Remember YO goes 
with player 0, Yl with player I, Y2 with player 2, and so on. Remember, too, that 
the fifth player is called Player 4.) 

Horizontal Movement. Horizontal movement of the fifth player is not so 
easy. Each missile still keeps its own horizontal position register. So to move the 
fifth player horizontally (in one piece] you have to poke all four horizontal 
position registers. Assuming that you have all missiles set to normal width, you 
might do it like this: 

POKE HPOSM0.X4 
POKEHPOSM1.X4+2 

POKE HPOSM2.X4+4 
POKE HPOSM3.X4+6 



" 



' 
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All those POKEs add up and slowdown the animation loop. So here's another 
case where a machine language routine might come in handy, but that's the 
subject of my next book. 

Even though these separate horizontal position registers pose a speed 
problem, you still might use them to good effect. For example, you might 
"blow up" the fifth player and scatter his pieces all over the screen. Or you 
might mysteriously create the fifth player by gradually moving his various 
pieces together. 

Collision Detection. Another consideration is collision detection. Each mis- 
sile still has its own collision detection register. That could be interesting. For 
example, you might specify that your player is vulnerable only if he is hit in the 
right arm. (He couldn't be hit by a missile, of course, but he might be hit by a 
"laser" created with a DRAwTO statement. Or he might be hit by another 
player.) 



MULTICOLORED PLAYERS 

So far each player has only one color. But if you want, you can overlap player 
with player 1 (or player 2 with player 3). In the area of overlap, a third colorwill 
be produced. In effect, then, you can have a three-colored, animated object. To 
make this work, you must first add 32 to the value that you would otherwise 
poke into the priority register (location 623). 

■ Let's try a problem to clarify that. Suppose you want your players to have 
priority over playfields. Normally, you'd poke 1 into 623. But let's say you 
want a fifth player and you also want to combine player and player 1 to 
create a multicolored spaceship. How would you code the poke into 
location 623? 



ANSWER 
POKE 623,1+16+32 (or POKE 623,49) 






GRAPHIC SHAPE REGISTERS 

Now let's turn to another topic: the graphic shape registers. So far we haven't 
needed these registers. That's because we allocated a special area in memory 
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to contain the PM shape data. And as you will recall, we told ANTIC where this 
PM memory area was by poking the address of BUFFER into location 54279. 
(To review, see "PMBASE" in Chapter 4.) 

Also, we set up what is called "direct memory access" by poking location 
559 with an appropriate value. In addition, we specified the type of resolution 
we wanted by poking location 53277. 

Well, if you use the graphic shape registers, you can bypass ANTIC, and 
you don't have to poke anything into locations 54279, 559, or 53277. Conse- 
quently, your PMG setup is greatly simplified. 

But the graphics shape registers are not so great for animation. That's 
because each can contain only one byte of data. They are useful, though, 
when you want to display a player image the entire length of the screen. You 
might want to do this to highlight textual material or to create a special 
boundary for a playfield. 

Here are the graphics control registers for each of the players: 

Player Number Location 

53261 

1 53262 

2 53263 

3 53264 

The graphics shape register for all of the missiles is at location 53265. 
Even though each graphics shape register holds only one byte of image data, 
that byte runs the entire length of the screen. You'll see an example of these 
registers in action in a moment, but first I'd like to expand on DMACTL, the 
direct memory access control register at location 559. 



DMACTL 

You can specify different options using this register. In the chart below, just add 
up the options you want. Then poke the total into location 559. But note that 
you must pick only one of the first four options: 

Value to Poke 
Option into 559 

No playfield 

Narrow playfield 1 (pick one) 

Standard playfield 2 

Wide playfield 3 



" 
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Missiles 4 

Players 8 

Single-line resolution 16 

Double-line resolution 32 

Note: you won't be able to see the edges of the wide playfield unless 
you scroll off the usual screen. 



SAMPLE PROGRAM 

As usual I will end this chapter with a sample program. The program illustrates 
the use of: 



PMG in graphics mode 

The fifth player 

Priority selection 

Playfield size selection 

Overlapping of players to get multicolored objects 

A simplified PMG setup (using the graphics shape registers) 

If you have written programs in graphics 0, you may want to consider 
spicing them up with some of the techniques demonstrated in this program. 
Happy hacking! 



1 60T0 4 

2 SAVE "D: GRAFF. SAV": STOP 

4 ? CHR*(125) :REM CLEAR SCREEN 

5 POKE 752,1: REM TURN OFF CURSOR 

7 GOSUB 500: REM SIMPLIFIED PMG SETUP 
10 POSITION 2,10:? "In this example," 
20 ? "we ars NOT using" 
25 ? "ANTIC or Direct" 
30 ? "Memory Access" 

32 ? "to fetch Players " 

33 ? "or Missiles." 

35 GOSUB 900: REM Ha it for user to pre. 
s a key. 

36 ? CHR*(125) :REM CLEAR SCREEN 

40 POSITION 24,9:? "Notice how easy" 
42 POSITION 24,10:? "it. is to add " 
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44 POSITION 24,11:? "Color to " 

46 POSITION 24,12:? "Oraphics Mode 0. " 

50 DELAY=300: GOSUB 700: REM PAUSE FOR ft 

MOMENT 
60 POSITION 24,16:? "Like thi s !": DELAY 
=50: GOSUB 700 

62 POKE 53248, 176: POKE 53249, 144: REM P 
UT PLAYERS ON SCREEN 
65 DELAY= 100: GOSUB 700 
70 POSITION 24,18:? "It's also easy" 

80 POSITION 24,19:? "to change that" 

81 POSITION 24,20:? "col or . " : DELAY=200 
:GOSUB 700 
85 FOR 1=0 TO 254 STEP 10: X=5'-3: POKE 7 
04, I: POKE 705,I:NEXT I : REM H~5 A 3 is ad 
ded here simply to add a pause 

90 POKE 704, 80: POKE 705,80 

100 GOSUB 700 

102 ? CHR*(125) :POSITION 2,3 

105 ? "And it's easy to" 

106 ? "go back to the regular" 

107 ? "play-field color." 

108 GOSUB 900 

1 1 POKE 53248 , : POKE 53249 , : REM MOVE 

PLAYERS OFF SCREEN _ 

115 GOSUB 700 

117 ? CHR*(125):? :? :POSITION 2,3 
120 ? "You can also fill" 
125 ? "the entire screen" 
130 ? "with all 5 players." 
135 DELAY=400: GOSUB 700 

140 ? :? "Like so:":X=X"3 m 

150 GOSUB 1000: REM MOVE ALL 5 PLAYERS 
ONTO SCREEN 
230 GOSUB 700:? CHR* ( 125) : POSITION 2,3 

232 ? "The play-field is now hiding" 

234 ? "behind the players.":? :? 

235 DELAY=250: GOSUB 700 

236 ? "Now I'll put it in front" 

238 ? "of the players." 

239 DELAY= 100: GOSUB 700: POKE 623,4+16 

240 DELAY=500: GOSUB 700:? CHR*(125):P0 
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" 



SITION 2,10:? "Next, when you press a 
key, " 

241 ? "I'll shrink the play-field" 

242 ? "for a moment by poking ":? "Loc 
ation 559 with 33. " 

243 GOSUB 900:? CHR* ( 125) : POKE 559,1+3 
2 : DELA Y=200 : GOSUB 700 : POKE 559 , 2+32 

244 ? :? :? "Next, let's set each play 
er" 

245 ? "to a different color." 

246 gosub 900: poke 559,2+32 

247 poke 704, 16: poke 705, 64: poke 706,9 

6: poke 707, 144: poke 711, 192: rem set pl 
fivers to different colors 

248 ? chr* (1 25 ): gosub 700 

250 POSITION 2,3:? "Notice that player 

s " 

252 ? "0-3 sre behind the play-field" 

254 ? "but Player 4 (at right)" 

255 ? "is in front of the play-field." 
260 GOSUB 900 

265 ? CHR* ( 125) : POKE 623, 4+16: REM SET 

PRIORITIES AND ENABLE 5TH PLAYER 

270 POSITION 2,3:? "As you can see, PI 

ayer 4" 

272 ? "(the one made up of missiles)" 

274 ? "always displays in front of" 

276 ? "all play-fields. ": GOSUB 900:? CH 
R*(125) : POSITION 2,3 

277 ? "Let's get rid of the ":? "playf 
ield again. ": GOSUB 900:? CHR* ( 125) : POK 
E 623, 1+16: POSITION 2,9 

278 ? " Playf ield now hi di ng. ": GOSUB 
900 

280 ? CHR* ( 125) : POKE 623, 4+ 16: POSI T ION 



282 ? "In conclusion, here's an" 

283 ? "example of how you can" 

284 ? "overlap players to create" 
286 ? "a multicolored object." 
290 GOSUB 900:? CHR* (125) 

292 POKE 623, 1+16+32:REM ££7 PRIORITY, 
ENABLE 5TH PLAYER, CREATE MULTICOLORED 
OBJECT MHEN PLAYERS OVERLAP 
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299 REM SET PLAYERS AND 1 TO OVERLAP 



300 
310 
320 
350 
360 
370 
380 
390 
400 



POKE 
POKE 
POKE 
POKE 
POKE 
POKE 
POKE 
POKE 



53248, 48: REM PLAYER 
53249, 48+16: REM OVERLAP 
53250,0: REM MOVE OFF SCREEN 

53252, 
53253,0 
53254,0 



>25J 







POSITION 18,10:? "The three colors 



410 POSITION 18, 11 

420 POSITION 18, 12 

425 POSITION 18, 13 

430 POSITION 18,15 



"at left were " 
"produced by" 
"Players & 1. " 
"You can use the" 



432 POSITION 18, 16: 
434 POSITION 18, 17: 
436 POSITION 18, 18:' 
438 POSITION 18, 19: 
440 POSITION 18,22:' 

499 GOTO 499 

500 POKE 623,1+16:REM 
IN FRONT OF PLAYFIELD : 
ER 

505 POKE 53256, 3". POKE 
58, 3: POKE 53259, 3: REM 
TO QUADRUPLE HI DTP 
507 POKE 53260, 192+48 

MISSILES TO QUARUPLE 
510 POKE 704, 80: REM S 



"same idea to" 
"make a multi-" 
"colored flying" 
"spacecraft ! " 
'•END OF PROGRAM" 

DISPLAY PLAYERS 
■ ENABLE 5TH PLAY 

53257, 3: POKE 532 
SET ALL PLAYERS 

+12+3:REM SET ALL 

MIDTH 
ET PLAYER COLOR 



512 

514 

516 

518 

559 

HE 

560 

RO 

570 

575 

580 



POKE 
POKE 
POKE 
POKE 
REM 
PLAYER 



705, 80: REM PLAYER 



COLOR 

706, 80: REM PLAYER 2 COLOR 
707, 80: REM PLAYER 3 COLOR 
7 1 1 , 80 : REM PLAYER 4 C OL OR 
POHE DATA DIRECTLY INTO THE 
GRAPHIC REGISTERS 



POKE 53261, 255: REM IMAGE FOR PLAYE 



POKE 
POKE 
POKE 



5262, 255: REM 



53- 



63, 255: REM 
64, 255: REM 



PLAYER1 
PLAYER 2 
PLAYER 3 
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582 POKE 53265, 255: REM PLAYER 4! 

699 RETURN 

700 FOR 1=1 TO DELAY: NEXT I 
710 RETURN 

BOO IF PEEK (764)0255 THEN POKE 764,25 
5: RETURN 
810 GOTO 800 

900 POSITION 2,22".? "TAP ANY KEY":? "T 

CONTINUE" :GOSUB 800 

910 POSITION 2,21:? " ":? 

II II 

920 RETURN 

999 REM HOVE ALL PLAYERS ON SCREEN 

1000 POKE 53248, 48: REM HOR. POS . PO 
1010 POKE 53249,48+32 

1020 POKE 53250,48+2*32 

1030 POKE 53251,48+3*32 

1040 POKE 53252,48+4*32 

1050 POKE 53253, 48+ (4*32) +8 

1060 POKE 53254, 48+ (4*32) +16 

1 070 POKE 53255 , 48+ ( 4*32 ) +24 
1080 RETURN 



' 
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Player Color Location 



Player 



1 

2 

3 

4 (missiles) 



Location 

704 
705 
706 
707 
711 



A guide for designating your player's color: 



Color 



Gray 

Gold 

Orange 

Red 

Pink 

Violet 

Purple 



Number 


16 

32 
48 
64 
80 
96 
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Blue 112 



Blue 128 

Light Blue 144 

Turquoise 160 

Blue-Green 176 

Green 192 

Yellow-Green 208 

Orange-Green 224 

Light Orange 240 

These numbers are starting numbers. To any given number you can add 
an even number from to 14 to change the lightness of the color. 



Player Missile Memory 

To tell ANTIC where the start of PM memory is we simply poke the proper 
address into location 54279, the player-missile base register. Example: 

POKE 54279,ADR(BUFFER$) 

Location 559, DMACTL 

Choose the options you want and add up their values. Poke the total into 559. 



" 



Option 


Value 


No playfield 





Playfield size: 
Narrow 
Standard 
Wide 


1 
2 

3 


Turning on: 
Missiles only 
Players only 
Missiles and players 


4 

8 

12 


Single-line resolution 
Double-line resolution 


16 



Turn on DMA 


32 
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Location 53277, The Graphics Control 
Register (GRACTL) 

Use this location along with 559 to "turn on" the PMG system. 



If you want: 



Then: 



Missiles only 




Poke 53227,1 


Players only 




Poke 53277.2 


Players and Missiles 


Poke 53277,3 


Horizontal Position 


Registers 




Location 




Player 


53248 







53249 




1 


53250 




2 


53251 




4 


Location 




Missile 


53252 







53253 




1 


53254 




2 


53255 




3 



Horizontal Coordinates 




HORIZONTAL 
COORDINATES 
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Joystick Reading 

Peek into these locations to read joystick values. 






Location 

632 
633 
634 
635 



Joystick Number 


1 

2 
3 



Joystick Values 

This diagram shows the values produced when you move the joystick in 
various directions. Note that if you do not move the joystick, a value of 15 is 
produced. 




Sound Registers 



Location 


Used to Control 


53760 


Pitch of voice 


53761 


Distortion and volume of voice 


53762 


Pitch of voice 1 


53763 


Distortion and volume of voice 1 


53764 


Pitch of voice 2 


53765 


Distortion and volume of voice 2 



53766 
53767 

53768 
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Pitch of voice 3 

Distortion and volume of voice 3 

Pitch of all voices 



with: 



Note: before using pokes to create sound, initialize the sound system 

POKE 53768,0 
POKE 53775,3 
(Or simply code: SOUND 0,0,0,0) 

Location 53768 can be used to control the quality of sound. For example, 
you can filter out certain frequencies or combine two channels to improve pitch 
range and accuracy. See the book De Re Atari for details. (Available from Atari 
Program Exchange.) 

Missile Collisions 



" 



Memory Location 


Shows: 


53248 


Missile to playfield collision 


53249 


Missile 1 to playfield collision 


53250 


Missile 2 to playfield collision 


53251 


Missile 3 to playfield collision 


53256 


Missile to player collision 


53257 


Missile 1 to player collision 


53258 


Missile 2 to player collision 


53259 


Missile 3 to player collision 



Player Collisions 



Location 


Collision Shown 


53260 


Player to player 


53261 


Player 1 to player 


53262 


Player 2 to player 


53263 


Player 3 to player 


53252 


Player to playfield 


53253 


Player 1 to playfield 


53254 


Player 2 to playfield 


53255 


Player 3 to playfield 
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Location 53278, Hit Clear Register 

To clear all collision registers, poke a 1 into HITCLR (location 53278). 



Value to Poke into 623 



1 



Location 623, Priority Register 

Display Priority 

All players in front of all playfields. 

Players 2 and 3 behind playfields; 
players and 1 in front of 
playfields. 

All playfields in front. 

Players in front of some play- 
fields, but behind others. 



Suggestion; Experiment! Move your players over various playfield objects 
to discover the effect of various priority settings. 

Other Options for Location 623 

Pick the desired options and add up the values. Poke the total into location 623. 



Option 

Combine missiles to make a 5th player. 
Overlap players to make a third color. 

Graphics Shape Registers 

Player Number 


1 

2 

3 

All missiles 



Value 
16 

32 



Location 

53261 
53262 
53263 
53264 
53265 







Index 
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A 
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Animation 47, 65 


Images 




B 


Defining 65 




Binary numbers 10 


How stored 6, 67 




Boundary 


J 




One K 21 


Joystick control 51, 53 




Two K 109 


L 


- 


C 


Lasers 139 




Chords 79 


Leemon, Sheldon 




Clearing strings 28 


article on using strings 19 




Collisions 


Legs, making move 65 




Detecting 137 


M 




Registers 117 


Machine language 131 




Multiple 120 


MAZEDUEL.SAV 142 




Player 123 


MISSCOLSAV 126 


Missiles 125 


Missile 




Reading 119 


Horizontal position 92 




COLOR 1 playfield 121 


Image 89 




Colors, selecting 136 


Move routine 93 




D 


Size register 103 




Decimal numbers 15 


Moving two players 138 




Designing images 8 


Multicolored players 43 




Diagonal movement 50 






DMACTL 38,156 


O 




Double line resolution 20 


One K boundary 21 




E 


ONSCREEN.SAV 43 




Error routine 101 


P 




Errors, trapping 73 


Pixel 6 




F 


PM data, look at 61 




Filler code 22 


Priorities 55 




Five players 153 






G 


R 




Game Programming 135 


Random numbers 




Garrett, B. B. 


in a game 139 




on execution speed 118 


missile size 104 


_ 


GRACTL 39 


Reading collisions 119 




GRAFP.SAV 157 


S 




Graphic shape registers 155 


Seyer, Dan 




H 


collision detection 




Highlighting text with PMG 157 


routine of 137-138 




Horizontal movement 49 


Shadow register 55 




HPOSP0 40 


Simplified PMG setup 157 
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Single line resolution 109 
SLRES.SAV 112 
Sombrio, Robert 

Joystick routine of 53 
Sound 

Demo 81 

Registers 81 

Statement 77 

Traveling 84 
SOUNDRUN.SAV 86 



Speed, changing 58 
Strings 
Storing images in 6, 67 
T 
Two K boundary 109 

V 
Variable names 118 
Vertical position 41 
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$14.95 



ATARI® Home Computers have a secret feature that 
sets them apart from other personal computers. Now 
you can-find out all about this secret feature and how 
to use it. It's called player-missile graphics— with it you 
can create all kinds of special effects! It has many excit- 
ing features that not only will make game programming 
easy, but also will make other types of programs — 
educational, business, etc.— more interesting and entec- 
taining. Player-missile graphics will enable you to 
custom-design graphic images, make them any color 
you want, change their size, move them independently of 
each other, and even create sound to accompany your 
graphics "players"! For example, in a music program 
you could use players for notes and have them dance 
across the screen along with the music. ATARI Player- 
Missile Graphics will take you step by step through all 
this and more. You'll find out everything you need to 
know to create sophisticated graphic effects far beyond 
the reach of most personal computers. 
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